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2. Preface 


This document is a collection of writings concerning the application of Global Positioning System (GPS) 
technology to the International Space Station (ISS), Space Shuttle, and X-38 vehicles. An overview of how 
GPS technology was applied is given for each vehicle, including rationale behind the integration 
architecture, and rationale governing the use (or non-use) of GPS data during flight. For the convenience 
of the reader, who may not be interested in specific details of the ISS, Shuttle and X-38 applications, the 
lessons learned chapter is at the beginning of the document. Most of this material can be understood 
without reading the sections specific to the ISS, Shuttle and X-38. 

These lessons were written mainly from the perspective of NASA and contractor personnel (both 
technical and management) supporting the Mission Operations Directorate at the Johnson Space Center 
(JSC). Additional perspective on GPS integration experiences and lessons learned can be obtained by 
contacting the JSC Aeroscience and Flight Mechanics Division, Code EG (Engineering Directorate). 

GPS has also been applied to space applications by other NASA centers (Goddard, Jet Propulsion Lab, 
Marshall). Personnel supporting GPS applications at these centers can also provide insight into 
challenges associated with GPS integration. 
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3.1 ntroduction 


In the early 1990s, use of Commercial or Modified Off The Shelf (COTS or MOTS) hardware and software 
became a prominent theme in government and industry in order to reduce procurement, development 
and integration costs. At the same time, in an attempt to revitalize the U.S. space program, a "faster- 
better-cheaper" approach to spacecraft development and mission execution was being stressed within 
NASA. 

By the early 1990s, after over 20 years of development of the Global Positioning System, the GPS satellite 
network and associated ground support infrastructure was nearing operational status. GPS receivers for 
scientific, commercial, consumer and military applications were entering the marketplace. GPS was 
anticipated to provide the revolutionary capability of precision navigation at low cost and at a minimum 
amount of effort on the part of the user. GPS receivers have the potential to provide cheaper, more 
accurate and timelier state vectors than traditional ground tracking. GPS is an enabling technology for 
small satellites operated by organizations that cannot support an operations infrastructure. To lower 
spacecraft operating costs, there is a desire to build spacecraft that operate in a more autonomous fashion 
and require fewer or no ground support personnel. 

At this time, the NASA Johnson Space Center initiated a number of projects designed to leverage GPS 
technology to meet the needs of current and future manned spacecraft. Use of off-the-shelf GPS receivers 
was believed to be the key to introducing low cost, precision navigation into human space flight, and to 
reduce integration, certification, and maintenance costs. These spacecraft included the Space Shuttle [1], 
the ISS [2] and the X-38 [2, 3], a prototype of a Crew Return Vehicle (CRV) for the ISS. The receiver 
integrated into the Space Shuttle avionics system was the Miniaturized Airborne GPS Receiver/Shuttle 
(MAGR/S), while the ISS and X-38 used the Space Integrated GPS/Inertial Navigation System (SIGI). In 
addition, a mission control software tool called the Spacecraft Position Optimal Tracking (SPOT) filter 
was developed to process Shuttle and ISS GPS receiver data to provide more accurate orbit determination 
for mission planning. The use of GPS by the Shuttle, ISS and X-38 is not as extensive as some might 
expect, given the widespread use and success of GPS technology, and the availability of ~$100 receivers to 
the general public. The rationale behind the current planned use of GPS by the Shuttle and ISS Programs 
is discussed along with some project history. 

While the Shuttle and ISS integrations were successful (the X-38 was canceled), more technical and project 
management challenges were encountered than anticipated. More GPS receiver software changes, host 
vehicle flight software changes, and flight and ground testing were required than anticipated, which in 
turn caused schedules to slip. 

Two incidents involving GPS, one on the ISS and another on the Space Shuttle, had a profound effect on 
the direction and execution of the GPS integrations. During the STS-91 (June 1998) flight of Discovery, a 
GPS receiver software problem interacted in an unanticipated manner with existing Shuttle flight 
computer software requirements which were deficient and resulted in a loss of communication with 
Discovery for over an hour. 
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On the ISS in September of 2002, a GPS receiver software error not recognized in ground testing caused 
an ISS computer system to go into a diagnostic mode. The incident impacted the ISS in the following 
ways: transfer of attitude control from the U.S. segment control moment gyros to the Russian segment 
thruster system; contingency attitude control using valuable and carefully managed propellant supplies; 
labor intensive manual S band antenna pointing by Mission Control in Houston to maintain data and 
voice communications; loss of Ku band data transmission capability; loss of micro-gravity environment 
due to attitude control thruster firings; and loss of a crew day of science operations. 

Shuttle GPS receiver. Shuttle computer and ISS GPS receiver software changes were later made. Lab 
testing and flight experience proved that the changes resolved the software problems. 

GPS receiver procurement, pre-flight testing, integration, numerous test flights in space and on aircraft, 
data analysis, issue resolution, interaction with the GPS community (vendors, users and satellite 
operations personnel), and participation in navigation industry conferences has provided Johnson Space 
Center personnel with insight into the advantages and difficulties posed by GPS technology. Many 
observations and lessons learned from these projects may be useful for reducing risk in other GPS 
implementations, and any project that concerns the infusion of software intensive technology. 

Future applications such as formation flying, elimination of ground tracking, autonomous operation and 
automated orbital replenishment (rendezvous, proximity operations and docking) will place stringent 
demands on GPS receivers. Software quality, hardware reliability and orbit determination accuracy 
requirements to support these applications will be more demanding than the capabilities of current, 
Commercial-Off-The-Shelf (COTS) based GPS units. Lessons learned from experiences in the Shuttle, ISS 
and X-38 programs should be studied to mitigate risk in future programs that require highly accurate, 
robust GPS navigation and GPS attitude determination to support automation and autonomy 
requirements. 
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4. The Software Nature of Satellite Navigation 


Threats to I ntegrity 

Risks to GPS (or GNSS, Global Navigation Satellite Systems) integrity include radio-frequency 
interference (intentional or unintentional), spoofing, ionospheric and solar effects, user errors, multipath, 
signal obscuration, antenna failure, failures in computers that interact with GNSS receivers, and 
malfunctioning GNSS satellites or ground support systems [4]. The effects of on-board satellite 
equipment failures, or ground control segment induced anomalies, may affect users over a wide area. 
Spectrum sharing and the effects of new radio-frequency technologies, such as Ultra Wide Band, are 
important issues that must be resolved at the engineering, government policy and regulatory levels. The 
navigation industry and government agencies are actively researching the potential of GNSS integrity 
threats and building systems (such as WAAS, LAAS, EGNOS) and procedures to detect, identify and 
mitigate them [5]. Much research has been performed on receiver algorithms (such as Receiver 
Autonomous Integrity Monitoring, or RAIM) to detect signal-in-space issues [6]. 

These are not hypothetical threats. On July 28, 2001, the failure of a rubidium clock on GPS satellite PRN 
22 was detected by the WAAS, the U.S. Coast Guard and GPS receivers that were equipped with RAIM 
algorithms [7]. A well-publicized example of unintentional interference was noticed in Moss Landing 
Harbor, California, in April of 2001. Several months of investigation resulted in the identification of three 
boat mounted, active UHF/VHF television antennas with preamplifiers, that were the source of the 
interference [8]. 

Software Quality and GNSS I ntegrity 

Over the last 40 years, integration of off-the-shelf systems had changed from being primarily hardware 
integration to software integration. This presents new challenges for users of off-the-shelf systems. 
Developers of such systems must compete in a market that demands short time-to-market and low 
overhead. This results in short development and test cycles, less rigorous requirements definition and 
documentation, and a small group of programmers; and it can lead to a higher probability of software 
errors. Some products contain legacy code that may be decades old, and proper coding standards may 
not have been adhered to. Vendors often maintain a library of common software modules used in a 
variety of products. Cost and schedule concerns may lead the vendor, integrator, or user to judge a 
software issue to be no impact and not fix it. However, this can lead to propagation of software problems 
throughout a product line, and it could negatively impact users whose applications of the product in 
question are different from the original user. 

Historically, navigation unit problems and failures in the legacy Shuttle navigation system tended to be of 
a hardware nature. However, most problems observed by JSC with GPS have concerned software. GPS 
receivers contain tens or hundreds of thousands of lines of code. Code errors may not always manifest in 
a predictable or easily observable manner and may lie dormant for years until the proper set of 
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conditions permits them to become visible. Software errors that do not manifest in an aircraft application 
of a GPS receiver may be an impact in orbit, where vehicle dynamics, satellite visibility, and flight times 
are very different. 


Software is at the heart of the GNSS revolution. Receivers, ground monitoring stations, augmentation 
systems, GNSS satellites and associated constellation ground support equipment are software intensive. 
The computational capacity and amount of code possessed by GNSS receivers is approaching that of 
aircraft flight management systems and flight control computers. Some current and many future GNSS 
receivers will interface with multiple systems: GPS, Galileo, GLONASS, WAAS, LAAS, EGNOS and 
various differential systems. Multiple system interfaces will further increase the software complexity of 
GNSS receivers. With this revolutionary navigation capability has come increased potential for 
performance anomalies due to software issues. 

Receiver software problems can result in degraded navigation accuracy, or loss of navigation data for a 
variable amount of time. Most of the threats under examination by the navigation industry and 
government agencies are external to GNSS receivers. External monitoring, augmentation systems and 
receiver based RAIM will protect against software failures external to the GNSS receiver, but will not 
protect a user from a GNSS receiver software problem. 

Receiver failures are not always well documented and may not be noticed if a device is not continuously 
monitored and data is not recorded and analyzed. If a problem is noticed, the reports often tend to be 
anecdotal in nature. It is difficult to pin down the cause of many GNSS receiver issues (i.e., intentional or 
unintentional radio-frequency interference, multipath, signal obscuration, antenna failure, hardware 
failure, receiver software failure, host computer hardware or software issues, operator error). Users are 
sometimes too quick to blame a receiver problem on a "bad" satellite or receiver software "bug," when 
the root cause is more likely a user error stemming from inadequate knowledge of receiver operation. 

Engineers often underestimate the complexity of software, and overestimate the effectiveness of testing 
[9]. Tasks in GNSS receivers are started and stopped based on priorities, and the ability to track GNSS 
satellites. Logic path execution in a receiver is dependant on the radio-frequency environment, 
introducing an element of randomness into what code is executed, and when. A number of Shuttle 
receiver problems identified during a GPS receiver code audit were deemed non-credible due to the 
number of conditions that had to occur within a tight timeframe. However, many of these issues later 
manifested in Shuttle flights, sometimes more than once. Receiver software modifications were made, 
proven in lab testing and during Shuttle missions, and the Shuttle GPS system was certified for 
operational use in August of 2002. GNSS satellite signal generators used in lab testing cannot duplicate 
the exact radio-frequency environment encountered outside the lab. Receiver software anomalies that 
manifest in flight may not manifest in ground testing. The Shuttle and ISS experience also indicates that 
changes to receiver software can result in subtle, unintended changes in receiver performance. 

Changes in operating environment that come with a new application may invalidate assumptions made 
during initial requirements definition, and result in software issues during testing and operation. 
Software development schedules driven by time to market pressures and a desire to lower overhead 
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costs (a small group of requirements developers and programmers, short development and test cycles) 
negatively effect software quality. A recent study of stand-alone TSO C-129 certified GPS receivers 
performed in the United Kingdom found that the probability of a receiver outage (loss of service) due to a 
software problem was higher than a signal-in-space problem that RAIM is designed to detect and isolate 
[10]. Data analyzed was collected during a total of 78,384.1 hours of receiver operation. The study 
concluded that more attention should be paid to characterizing GNSS receiver outage probability and 
outage modes. NASA's experience with the Shuttle, ISS, and CRY GPS receivers supports these findings. 


Computer I ntegration Versus Plug and Play 

Many applications of GNSS receivers involve interfacing with other computer systems. The concept of 
"plug and play" assumes that no software or hardware changes are required during integration. This is 
not a safe assumption for many applications. Different users may have different data and commanding 
requirements, and may not be able to economically change the rest of the system to conform to available 
receiver input and output. Hardware changes for items such as mounting or electrical power may also 
be required. Interactions of receiver software and software in other parts of a system cannot be assessed 
without testing and design insight, no matter how many applications already use the receiver in 
question. A "plug and play" integration assumption, which drives initial budget and schedule planning, 
can easily result in schedule slips and cost increases due to unanticipated technical problems at the 
component and system levels. 

Successful integration of computers requires knowledge, not just of the interfaces, but also of how the 
data behind the interfaces are computed and behave under nominal and off-nominal conditions. An 
integrator may have to negotiate legal agreements concerning access to proprietary documentation with a 
vendor, so that information needed for integration is available. Integrator verification of interface 
documentation in a laboratory environment is prudent. System problems may result from the 
inappropriate interaction between parts of a system, such as computers, rather than individual units. The 
root causes, manifestations and impacts of system components that behave in a dysfunctional manner are 
difficult and sometimes impossible to predict. 
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5. GPS Lessons Learned 


Since 1993 numerous flights of GPS receivers have been made on the Space Shuttle (Table 1) in support of 
Shuttle navigation upgrades, testing for the International Space Station, X-38, X-33 and X-34 programs, 
relative GPS technology development, and various other payloads and projects. In addition, GPS has 
been in operational use on the ISS since April of 2002. GPS units are flying on the Shuttle Training 
Aircraft, and flew on X-38 landing demonstration vehicles when dropped from the NASA B-52B at 
Edwards Air Force Base. X-38 GPS tests were also conducted on a NASA Beechcraft Beech 200 Super 
King Air based at the NASA Dryden Research Center. This experience base can be leveraged to mitigate 
risk in new applications of GPS technology to space flight. 


Table 1 - GPS Flights on the Shuttle and Shuttle Payloads (1993 to 2005) 


Purpose 

Unit Flown a 

Flights b 

Space Shuttle 

3M 

61, 59, 68, 67, 69, 72, 77 

Navigation 

MAGR 

79, 81, 82, 84, 85, 89, 91, 95, 88, 96, 103, 99, 101, 106, 92, 

Upgrades 


97, 98, 102, 100, 104, 105, 108, 109, 110, 111, 112, 113, 107, 114 


SIGI (GEM III) 

86, 89, 91, 95, 88, 96, 103 

ISS Testing 

TANS Vector 

77(GANE) 


SIGI (Force 19) 

101 (SOAR), 106 (SOAR) 

X-38 Testing 

SIGI (Force 19) 

100, 108 

X-33 & X-34 

LN-100G (GEM III) 81, 86 

Support 

H-764G (GEM III) 

84 

Relative GPS 

TurboRogue 

69 (WSF-02) 

Test 

3M 

69 

ATV Relative 

Laben Tensor 

80 (ORFEUS-SPAS 2), 84 c , 86 c 

GPS Test 

TANS Quadrex 

80 

Other Payload 

Actel 

51 & 80 (ORFEUS-SPAS 1 & 2) 

Support or 

Blackjack 

99(SRTM) 

Technology 

Low Power 


Demonstration 

Transceiver 

107 (CANDOS) 


TANS Quadrex 

51, 56, 66 (ATLAS 3) 


TANS Vector 

66 & 85 (CRISTA-SPAS 1 & 2), 72 (SPARTAN-206 OAST-Flyer) 


a For Embedded GPS/I NS units, the GPS receiver is in parenthesis. 

b Payload names are in parenthesis. ATLAS 3, GANE, SOAR, SRTM and CANDOS remained on the orbiter, the 
others were deployed and retrieved. There may have been other GPS equipped payloads that are not listed. 
C A Motorola Viceroy receiver was on the Mir space station. 


The Shuttle, ISS and X-38 GPS projects encountered technical, schedule and budget problems that were 
not anticipated. GPS technology proved to be more difficult to apply than was anticipated in the early 
1990s. In spite of the challenges, the Shuttle and ISS GPS projects eventually resulted in certified GPS 
receivers for operational use. 
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A number of lessons were learned during the requirements definition, integration, testing, certification, 
and operational phases of these projects. Consideration should be given to these lessons learned in any 
future application of GPS to space vehicles. 

Perhaps the most important lesson concerned people's perception of the maturity of GPS technology for 
space applications. The widespread success of GPS in myriad applications during the 1990s exceeded the 
expectations of those in the military navigation arena that designed and developed the system in the 
1970s and 1980s. The success seen in terrestrial applications of GPS was anticipated to occur in space 
applications, but more difficulty in the space applications was encountered than many expected. 
Optimism about the ease of application of GPS to space flight influenced budget, scheduling and project 
planning, which led to problems at both the technical and project management levels as the projects 
progressed. 

A paper presented at a 1998 Institute of Navigation conference covered the status and future plans for 
GPS on spacecraft. Part of the paper discussed reasons for difficulty encountered in development and use 
of GPS receivers for space flight: 

"While this technology holds great promise, its incorporation on spacecraft has been delayed for several reasons. 

. The tremendous success of the very lucrative terrestrial GPS market has, in fact, stifled the development of 

spaceborne GPS receivers. Companies with GPS expertise are more interested in the lucrative terrestrial-based GPS 
market. They are not interested in diverting their GPS talent on the relatively small space-based market. This has 
restricted the development of spaceborne receivers to meet the demands of future spacecraft requirements." [11] 

The paper went on to list the reasons why spaceborne GPS receivers have not matured as fast as receivers 
for terrestrial applications: the perception that GPS technology is mature and requires no research and 
development to fly in space; more lucrative GPS receiver market for terrestrial-based applications; 
differences between space-based and ground-based GPS reception; and the requirement for numerous 
flight experiments to climb the technological stair steps [11]. 


Mission I mpacts Of GPS Problems 


Government and the navigation industry have devoted a considerable amount of effort to ensuring the 
integrity and availability of satellite navigation to the user community to ensure safety [5]. However, the 
negative impact of GPS receiver malfunctions is not limited to safety-of-flight applications such as the 
Space Shuttle or commercial airliners. GPS on the ISS is not safety critical, but frequent Mission Control 
and crew intervention to resolve GPS receiver anomalies created additional work for crew and ground 
personnel. The September 2002 incident on the ISS also impacted science operations, and could have 
posed a risk to crew and vehicle safety due to the communications problems that occurred. In addition 
to the operations costs incurred from handling GPS receiver anomalies, a significant amount of effort was 
required to eventually resolve those anomalies. The interaction of requirements deficiencies in a GPS 
receiver and Shuttle computer software caused a one-hour loss of communications with Discovery during 
STS-91, and drove the Shuttle Program to make significant changes to the Shuttle GPS project. 
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Receiver issues and a lack of design insight negatively impacted several relative GPS technology 
demonstrations on the Shuttle [12-15]. The GEOS AT Follow-On (GFO) Altimetry Mission satellite (not a 
part of the Shuttle Program) was to use a combination of on-board GPS receivers and ground laser 
tracking (using an on-board comer cube reflector) to perform centimeter level orbit determination. 
However, GPS receiver issues forced the use of ground-based lasers alone [16]. 

The criticality of GPS to the success of the Shuttle Radar Topography Mission (SRTM) on STS-99 
(February 2000) led to the inclusion of two Blackjack receivers in the Shuttle payload [17]. The Shuttle 
MAGR/S was designated as a backup, and a second MAGR/S was carried to provide additional backup 
capability. Shuttle IMU and Mission Control processed Tracking and Data Relay Satellite System 
(TDRSS) tracking data were also identified as backups. While the Blackjack met a 60 cm positioning 
requirement, the effort spent on backup orbit determination methods underscores the importance of GPS 
to the success of a non-safety critical science application. GPS was also a critical part of the NASA 
sponsored Demonstration of Autonomous Rendezvous Technology (DART) mission. The DART vehicle 
carried two different GPS receivers (each from a different vendor) to ensure state vector availability [18].* 


Define Realistic Schedule, Budget, and Requirements 

The phenomenal success of mass produced, low cost GPS technology in the 1990s is evidence that it can 
be leveraged to provide more robust, economical and autonomous navigation for many different 
applications. This has led some to believe that applying GPS to spacecraft should be relatively 
straightforward, and require little expenditure on development, modification and integration. Many 
potential users of GPS technology fail to realize the complexity of GPS receivers, since some units can fit 
into a pocket and cost around $100. Experience has proven that GPS integration on spacecraft is not so 
straightforward. 

Overly optimistic expectations of the budget and schedule required for integration are often not fulfilled. 
More technical issues were encountered than were anticipated, driving up costs and slipping delivery 
schedules. Particular attention should be paid to how realistic the schedule is considering the complexity 
and technical risk involved. A study by the Aerospace Corporation of NASA projects that used a faster- 
better-cheaper approach indicated that mission failures resulted from highly complex projects on short 
development timelines [19-21]. 

Analysis at the start of a project should be conducted to determine risk to cost and schedule based on the 
technology level, the maturity of the technology and the difference between the planned application and 
the application for which the receiver was originally designed. Software complexity should also be 
examined. Technical risk must be taken into account when defining budget and schedule. Failure to do so 
can lead to cost and schedule problems [22]. Traditionally, navigation unit integration has revolved 
around hardware integration and testing (such as shock, vibration, thermal, radiation). However, with 
the increasing use of embedded computers software development, maintenance, and testing must be 
budgeted for as well. 

* When this document was submitted for publication, the report of the DART Mishap Investigation Board had not 
been publicly released. See "NASA Announces DART Mishap Investigation Board Members," NASA Press 
Release 05-105, April 22, 2005. 
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If extensive modifications and operation in a different environment are required, more testing will have 
to be performed. Provision for interim software versions should be provided in the budget. The vendor 
will have to be more involved than on “plug and play" integrations. Understanding the design rationale 
and original user requirements is important, and provision for discussing this with the vendor should be 
included. 

Lessons learned from users of the same or similar products should be considered, particularly when 
defining requirements for the COTS item. "Loose" requirements may be easily met with little or no 
budget impact. However, they could permit problems to go unnoticed and unresolved and could impact 
future use of the device. Such requirements result in a "let's see what we can get by with" attitude rather 
than a "let's do what is right for the application" approach. 

Some GPS receivers used on NASA spacecraft have a specified rate of receiver resets to recover from 
software anomalies of less than one per day [17]. Such a requirement, along with a maximum allowable 
solution outage time, will help motivate a vendor to pursue software issues. 


Off-The-Shelf Versus Development 

Everything I s Not Plug and Play 

The fact that a unit is in mass production and is a proven product does not mean that its integration into 
a different vehicle will be a simple, problem free "plug and play" project. A difference in application 
(such as aviation versus space flight) will result in the manifestation of software issues that may not have 
appeared in the original application. A unit is not likely to meet all requirements as is, and both software 
and hardware modifications may be needed to meet mission unique requirements and interface with host 
vehicle avionics, telemetry and power systems. Even a receiver originally designed for space applications 
may require changes to meet new requirements and resolve technical issues. 

Changes Will Be Needed 

Navigation and avionics units are becoming more software intensive, and the technical risk posed by 
software is difficult to assess. While GPS receivers have the potential to provide spacecraft with an 
autonomous precision orbit determination capability, most receivers do not contain navigation 
algorithms needed for this [23]. In addition to software concerns, "terrestrial" and "atmospheric" 
navigation units may have difficulty meeting hardware requirements for space flight in the areas of 
loads, thermal, data interfaces, electrical power, weight and volume. The ever-smaller size of electronics 
makes them more vulnerable to space radiation; hence radiation hardening, which is expensive, may 
have to be considered. The Shuttle MAGR/S unit, which represented an early 1990s technology level, met 
NASA space radiation requirements as built. However, SIGI units required expensive modification to 
meet radiation requirements. The GPS receivers on the NASA Gravity Probe B spacecraft are another 
example of modification of a receiver to meet unique mission requirements [24]. 
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A Fixed Price Contract May Not Be Appropriate 


A fixed price contract may be appropriate if the intended application of the device is the same or very 
similar to the application for which it was originally designed. In this case, little or no development work 
is required. However, if a unit is to be used in a flight environment that will necessitate significant 
changes to the device, the program budget and schedule should be allocated as for a development 
project. Fixed price contracts can result in inflated vendor estimates for initial cost and can remove the 
incentive to aggressively resolve technical issues. Resolution of these issues may not be covered in the 
budget defined at project start. Modifying an existing GPS receiver, even one originally designed for 
space, for use on an unmanned or manned spacecraft should be budgeted and scheduled as a 
development project. 

Building Your Own Receiver May Be An Option 

For some scientific applications, commercially available receivers may not meet mission requirements 
(accuracy, fully autonomous operations, special types of measurements, radiation exposure, size, power, 
etc.). Furthermore, such missions may have unique requirements that are difficult to meet with GPS 
receivers whose software is proprietary. One such vehicle is the NASA Johnson Space Center Miniature 
Autonomous Extravehicular Robotic Camera (Mini AERCam), a 7.5-inch diameter robotic inspection 
nanosatellite [25]. GPS vendors may be reluctant to support customization (i.e. a research and 
development activity) of a small number of receivers, for which a market does not exist. An example of 
an in-house scientific receiver is the Jet Propulsion Laboratory Blackjack, which has flown on ICESat 
(2003), FedSat (2002), GRACE (2002), JASON-1 (2001), SAC-C (2000), CHAMP (2000), and SRTM/STS-99 
(2000) [26], 

Commercially available GPS receiver kits supply GPS chip sets and traditional GPS software functions 
(signal processing, channel and data management, etc.) while allowing the user to add application 
unique software. Another advantage to kits is that the user has access to all software source code. 

However, building and flight qualifying an in-house receiver for space flight requires a high level of in- 
house GPS hardware and software expertise. Required skills that are not in-house may have to be 
obtained via contractors. Many projects may not have the schedule, budget, and technical resources 
needed to custom build a GPS receiver. Even if an off-the-shelf unit requires extensive modification, 
such a path may be less expensive than a custom built receiver or adaptation of a commercial GPS 
receiver kit. For safety-critical applications, such as the Space Shuttle, use of off-the-shelf units may be 
more appropriate. GPS vendors can leverage experience from a variety of safety critical government and 
commercial programs. Furthermore, some capabilities (such as ground or satellite based augmentation, 
authorized operation, mitigating radio-frequency interference, etc.) needed for receivers in safety critical 
integrations may require expertise that may not exist outside of the vendors. Vendor expertise and 
experience is crucial to successful requirements definition, receiver modification, integration, testing, 
anomaly resolution and certification of a safety critical receiver. 
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Working With Off-The-Shelf Items 


Recent analyses indicate that a lack of guidance on the application of COTS and faster-better-cheaper 
principles leads to projects that exceed cost and schedule estimates, and in some cases causes project 
failure [9, 10]. Some projects have failed or encountered significant problems since management and 
technical personnel were told to use COTS, but were not given (or did not seek) guidance on how to 
work with COTS, or determine if a COTS approach was even feasible. While much material has been 
published on the subject of COTS, much of it is highly theoretical. Many managers and engineers 
concerned with using COTS do not necessarily have the theoretical background to understand esoteric 
treatments of COTS theory. A key lesson from accident reports and experience papers reviewed by 
Shuttle operations personnel is that one must understand how to properly define, select and integrate 
COTS/MOTS components. Policies governing COTS and faster-better-cheaper approaches must be 
defined to permit clear and consistent application and to mitigate risk to budget and schedule [27-35]. 

Trade studies of COTS products involving "must meet," "highly desirable," and "nice to have" 
requirements will help determine what product to choose, what requirements it must meet, and if a 
custom approach should be taken instead. Any addition to or relaxation of requirements must be 
identified. A need for new requirements may not become visible until testing and implementation of the 
product is underway. The impact of COTS driven hardware and software changes to an integrated 
system must be assessed. 

COTS/ MOTS Policy 

A policy is needed to help prevent cost, schedule and technical difficulties from imperiling projects that 
use off-the-shelf items [27-37]. Criteria for determining whether a COTS approach can be taken must be 
determined. Of prime importance is defining the level of insight needed into vendor software, software 
maintenance and certification processes. Problems in COTS projects can arise when requirements are 
levied on the product that the vendor did not originally intend for the unit to meet. Using COTS may 
mean either compromising requirements on the COTS unit or on the integrated system. Whether or not 
new requirements have to be applied to the unit is a critical decision. Unfortunately, new requirements 
may not be recognized until the COTS product experiences difficulties in the testing and integration 
phases of the project. 

The Shuttle Program created COTS/MOTS software guidelines for varying levels of application criticality. 
This recommended policy defines what considerations should be made before deciding to procure a 
COTS/MOTS product. The following should be examined based on the criticality (impact of failure on 
safety of flight or mission success) of the application and product in question [38]. 

Certification Plan — How much of the vendors in-house certification can be relied upon? For critical 
applications, additional testing will be needed if access to test results, source code and requirements 
documents is not allowed. Can the unit be certified to a level commensurate with the criticality of the 
application? 
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Vendor Support — This should cover the certification process and the system life cycle. The level of 
support should be defined based on the criticality of the system. Vendor support required for testing, 
integration, and maintenance over the life cycle of the product must be defined. If white box testing 
(rather than black box testing) must be performed, design insight from the vendor will be required and 
proprietary agreements must be negotiated. The vendor may possess information on problems other 
users have encountered, which will be useful during integration and over the life cycle of the product. 
An additional risk in using "off-the-shelf" units concerns the availability of the vendor. Can a user 
continue to use and maintain a product if the vendor goes out of business or stops producing and 
supporting the product? 

Product Reliability — Vendor development and certification processes for both hardware and software 
should be examined. 

Trade Studies — Trade studies and risk identification must be performed before committing to the use of a 
particular unit and integration architecture. Define "must meet," "highly desirable" and "nice to have" 
requirements. Ability of the unit to meet those requirements, and at what cost, will be a major deciding 
factor in the COTS decision. Identify loss of operational and upgrade flexibility as well technical risks 
and cost associated with the product. Examine the impact of the product on the integrated system, 
including hardware and software interface changes. Compare the proposed COTS products to a custom 
developed product. Assess life expectancy of the product and it's track record in the market place. 

Risk Mitigation — Identify areas that increase risk, such as lack of support if the vendor goes out of 
business or the product is no longer produced. Ensuring vendor support over the product life cycle can 
mitigate risk, along with gaining access to source code, design requirements, verification plans and test 
results. Off-line simulations of the product should also be considered. Can access be obtained to vendor 
information on product issues discovered by other users? 

I mpact Of COTS Disappointments 

The success of inexpensive and easily available GPS technology has led some to believe that applying 
GPS technology is relatively straightforward, with low risk and low cost. Not understanding the 
complexity of GPS technology will lead to unrealistic budget, schedule, and technical success 
expectations. Assuming that "cheap and easy" terrestrial GPS means applying such technology to 
spacecraft will be "cheap and easy" has prevented the maturation of GPS units for use on spacecraft [11]. 

New technology projects may encounter significant technical problems, budget overruns and schedule 
slips due to unrealistic expectations that defined project budget and schedule. These experiences may 
cause both engineers and managers to become suspicious of the technology in question. The political and 
budgetary climate may demand a COTS solution, but problems using a certain technology can lead to 
reluctance to work with that technology in the future, particularly in a COTS project. The problem is not 
with the technology but with the unrealistic expectations that were attached to the new or off-the-shelf 
technology. These unrealistic expectations arise from a failure to appropriately investigate and plan for 
the use of a COTS product when defining schedule, budget, and requirements. These expectations are 
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based on a lack of understanding about the original design and application of the product in question. 
COTS products are "proven" devices only when used in the applications for which they were originally 
designed. The vendors met the contractual obligations of the original customer. The issue is not the 
technology, or the use of a COTS product, but rather how that technology was applied to meet the needs 
of the original customer. 


Take Advantage Of Lessons Learned 

When performing trade studies and risk assessments, previous users of the technology should be 
consulted. Independent consultants who have worked with a variety of units in different programs and 
who do not have a stake in the choice of a particular unit are a good source of information. Users and 
consultants may possess valuable knowledge based on hands-on experience that may not be available 
from a vendor. Consultants and other users can also provide valuable insight into the rationale and 
requirements that governed the original design of the unit. Taking advantage of such information 
enhances identification of cost, schedule and technical risks, and can help an integrator and user 
formulate more robust requirements. 

Starting in the mid 1990s, Shuttle operations personnel working on GPS began reviewing reports from 
accident investigations and spacecraft failures. A number of reports have been published highlighting 
the challenges of software development and analyzing failures of unmanned spacecraft, some of which 
used COTS and a "faster-better-cheaper" approach [27, 37, 39-50]. Some issues identified by those 
reports are listed in Table 2. 


Do Not Take Shortcuts With Process 

Process entails requirements definition, development of software, manufacture of hardware, verification, 
validation, integration, testing (at both the component and system level), data analysis, issue resolution, 
and certification by regulatory agencies. Problems in process can manifest as technical issues at the 
component or system level, user issues due to lack of understanding proper receiver or integrated system 
operation, schedule slips and cost overruns. Was the spurious active television antenna output that 
caused the recent GPS interference incident in California [8] the result of a process problem with design 
or manufacture? Process problems can delay the fielding of augmentation and improved constellation 
ground support systems that are needed to enhance navigation capabilities, and ensure integrity [51]. 

It is difficult to assess the quality of software requirements and code development processes when they 
are of a proprietary nature. Most software is not written from scratch, but is reused and modified for 
new applications. Development of legacy code may not have adhered to coding standards as it evolved, 
or been subjected to a robust process (requirements definition, code reviews, configuration management 
of code and supporting documentation, unit testing, lab testing of the receiver and integrated system, 
testing in the operational environment). Processes should be designed to focus resources on areas where 
the root cause of problems are frequently found. For example, many root causes of software issues occur 
during requirements definition and at hardware/software interfaces [52]. 
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Table 2 - Lessons From Other Programs 


• Technical risks not identified and managed. 

• Software development process not well 
defined, documented or understood. 

• Contract consolidation led to corporate 
knowledge loss concerning critical systems. 

• Lack of independent verification and 
validation. 

• Inadequate communication between project 
participants. 

• Lack of management involvement and 
oversight. 

• Inadequate spacecraft monitoring and 
procedural errors by operators. 

• Navigation equipment not well understood. 


• Spacecraft operators not familiar with 
system design, operation and failure modes. 

• Lack of a formal, disciplined process for 
documenting, advertising and resolving 
issues. 

• Inadequate staffing and training. 

• Legitimate issues ignored and attributed to 
resistance to a "new way" of doing business. 

• Frequent turnover of management and 
technical personnel. 

• Issues ignored due to cost and schedule 
pressure. 

• Roles and responsibilities not defined. 


The requirements definition, verification and validation processes require special attention [53]. Most 
software problems can be traced back to flaws in specifying requirements, not to coding errors [9, 54]. 

Flaws in requirements specification result from incorrect assumptions about system operation or 
unanticipated aspects of the operating environment. Requirements should also specify how a component 
or system should act under off-nominal conditions. 

Proper documentation of requirements, and requirements rationale, is important. Much software in use 
today is maintained by personnel who did not participate in the original development of the 
requirements and code [52]. Lack of documentation and corporate knowledge loss can pose technical, 
cost and schedule risk to projects that reuse existing software [55].* 

A review [9] of seven recent aerospace accidents identified sixteen common factors: 1) overconfidence 
and over reliance in digital automation; 2) not understanding the risks associated with software; 3) 
confusing reliability and safety; 4) over relying on redundancy; 5) assuming that risk decreases over time; 

6) ignoring early warning signs; 7) inadequate cognitive engineering; 8) inadequate specifications; 9) 
flawed review process; 10) inadequate safety engineering; 11) violation of basic safety engineering 
practices in the digital parts of the system; 12) software reuse without appropriate safety analysis; 13) 
unnecessary complexity and software functions; 14) operational personnel not understanding 
automation; 15) test and simulation environments that do not match the original environment; and 16) 
deficiencies in safety-related information collection and use. Many of these factors may be classified as 
problems with the processes used to develop, integrate and use devices and systems that contain 
software, which includes GNSS receivers and associated support systems. 

* John L. Goodman, Knowledge Capture and Management for Space Flight Systems, NASA Contractor Report 
CR-2005-213692, October 2005. Available at http://ntrs.nasa.gov/ 
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However, robust processes can be expensive [52]. A rigorous and successful process, such as that used 
for the Space Shuttle flight software, may not be economically viable for a vendor. Controversy over cost 
has surrounded the Federal Aviation Administration's DO-178B standards for avionics certification. 
Hiring and retaining skilled personnel to support these processes is challenging. 

Use of new or off-the-shelf technology has the potential to lower development, integration, and life cycle 
costs. However, successful use of a technology in other applications and environments does not mean 
that applying the technology in a new application or environment will be straightforward and low cost. 
Trade shows, conferences and industry magazines often do not highlight the technical and management 
challenges encountered when applying a new technology. The temptation to cut costs by cutting corners 
during requirements formulation [56], product or technology selection, development, integration, testing 
and certification should be avoided. False and simplistic perceptions of the maturity or flexibility of a 
technology can result in flawed processes that will increase technical, cost and schedule risk. Well- 
defined processes, clear lines of technical and management authority, accountability, and specific goals 
are required. Technical and management issues must be meticulously documented in a manner that 
provides visibility throughout the project. Clear lines of communication are essential to enable project 
members at both the organizational and individual levels to facilitate issue resolution. 

Technical issues must be addressed early in a project, even in the presence of cost and schedule concerns. 
These issues can easily become show-stoppers later in the integration. Not addressing issues until late in 
a project will drive up cost and shift schedules to the right. Problems arising from cost and schedule slips 
and failure to address issues can create adversarial relationships between project participants and the 
vendor. 

The data path from the receiver to the user needs to be completely and clearly defined. This includes on¬ 
board and ground hardware and software, and associated requirements documents. System 
requirements owners should also be clearly identified. New users of GPS data may experience difficulty 
in elevating concerns through unfamiliar and complicated software and hardware configuration control 
processes than encompass multiple spacecraft and ground systems. 


Lab And Flight Testing 

A number of spacecraft failures have resulted from a lack of comprehensive, end-to-end testing [9, 57]. A 
limited amount of flight and ground testing to ensure that the unit meets specifications may not exercise 
enough of the software to uncover software issues. If the new application is different from that for which 
the product was designed, and modifications have been made, the amount and scope of testing will have 
to go beyond that needed to verify that the unit meets contract specifications. Both off-line and 
integrated testing of interface software in units that interact with the COTS product are required. 


The ISS, X-38, and Shuttle GPS projects illustrated the need for thorough ground and flight-testing. The 
level of testing required varies with the criticality of the application. Sufficient resources and schedule 
should be provided to permit the appropriate level of testing to be conducted early enough in a program 


30 of 118 



to catch performance issues so that they may be resolved in a timely manner. If it can be afforded, 
extensive testing of the complete system and provision for interim software versions is highly desirable. 

Shuttle GPS - A Safety-Critical Application 

The Shuttle GPS receivers are required for hypersonic, supersonic and subsonic flight and landing of an 
-100 ton glider. As such, receiver and overall avionics performance are safety critical and must be highly 
reliable. The Shuttle test program permitted extensive ground testing of the MAGR/S in a stand-alone 
configuration with a signal generator, and integrated with a ground duplicate of the Shuttle avionics 
system. Multiple fly/fix/fly cycles of interim GPS receiver software versions were performed. 
Modifications of Shuttle flight computer software interfacing with the receiver were also identified and 
proven in ground testing and Shuttle flights (Table 1, page 21) before MAGR/S certification. 

The Shuttle/GPS integration architecture allowed a single GPS receiver to be flown for data collection 
while the baseline, certified legacy Shuttle navigation system operated. Shuttle software that interfaced 
with and processed MAGR/S data was exercised in flight. This integration architecture permitted flight 
evaluation of all hardware and software components of the GPS integration without requiring the use of 
GPS for Shuttle navigation. 

ISS GPS - A Non-Safety Critical Application 

A non-safety critical application may not warrant the same level of testing as a safety-critical application. 
The ISS GPS receivers, whose data support antenna pointing, time determination and provide state 
vectors to various users on the ISS, are not safety-critical. There are other methods of state determination 
available, such as GPS/GLONASS receivers on the Russian segment of the ISS, Russian ground tracking, 
and U.S. ground tracking. However, significant mission impacts can occur due to malfunctions of GPS 
receivers. While these impacts may not always threaten safety of flight, they may increase operations 
costs, drive extensive anomaly investigation and software changes, and prevent the accomplishment of 
science and mission objectives. However, dysfunctional interaction between a non-safety critical GPS 
receiver and safety-critical elements of an avionics system could pose a safety risk. Even for non-safety 
applications, an appropriate level of GPS and overall system testing must be determined to avoid threats 
to cost, schedule, and the achievement of mission objectives. 

The Difficulty of GPS Testing 

GPS receivers track and download data from multiple satellites. Signal strength, antenna obscuration, 
radio-frequency interference, and multipath can all effect the ability of a receiver to successfully perform 
acquisition, tracking, measurement processing, and data collection tasks. Software paths executed within 
GPS receivers are highly influenced by the radio-frequency environment. Test flights in the flight 
environment, as was accomplished with MAGR/S flights on Shuttle missions (Table 1, page 21), are the 
best way to test a receiver. Due to the integration architecture, these flights also exercised the same 
Shuttle computer software (GPS quality checks, telemetry, commanding, receiver aiding data, etc.) that 
would be supporting actual use of GPS after certification and TACAN replacement. However, this is 
expensive and may not be feasible in many applications. 
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Tests of the ISS and CRV SIGI units on the Shuttle (Table 1, page 21) were valuable, but they could not 
subject the SIGI units to the exact radio-frequency environment later encountered on the ISS. Nor were 
Shuttle flight tests of ISS SIGI able to exercise the complete GPS data path from the SIGI, through the ISS 
avionics and telemetry system, to the users in Mission Control. The first time ISS SPOT developers noted 
telemetry issues with SIGI data was after the SIGIs were operational on the ISS. GPS receivers may 
manifest performance problems after extended, continuous use (weeks or months) that may not manifest 
on shorter test flights. Some of the issues with the ISS SIGI unit could not have been caught during 
laboratory or Shuttle flight tests. While a non-safety critical application such as ISS GPS may not warrant 
the extensive test program that the safety-critical Shuttle MAGR/S was subjected to, there is risk of late 
discovery of performance issues that pose a risk to cost and schedule. 

Lab Testing 

Lab testing of GPS receivers is important for verifying data interfaces, commanding, basic functionality, 
receiver performance under dispersed trajectory conditions, and the ability of the receiver to operate in 
an integrated system. While GPS signal generators are useful for subjecting receiver software to flight 
dynamics, they cannot replicate the radio-frequency environment encountered in flight. Testing using 
roof-top antennas can also be useful, but cannot duplicate the flight dynamic or radio-frequency 
environments. Testing must not be limited to basic tests to ensure that the unit meets published accuracy 
and availability specifications. Extensive testing of both the receiver and interfacing host vehicle 
software using both nominal and off-nominal inputs should be conducted. Receiver anomalies will 
appear in flight tests that may not manifest during lab testing [17, 58]. Conversely, some anomalies 
found during lab testing may not occur in flight. 

Command and data collection interfaces should be exhaustively examined in lab testing prior to more 
expensive test flights. This will help ensure that interface and data collection problems do not occur 
which could make it impossible to verify receiver performance during a flight. Software issues that do 
not manifest in aviation applications due to a flight time of minutes or hours can manifest during a much 
longer space flight. For space applications, lab tests lasting many days or weeks should be conducted. 

Many software issues could have been found earlier in the Shuttle GPS project had a more thorough 
ground test program been conducted. A limited number of lab and flight tests to ensure that the box 
"meets spec" will not exercise enough of the software to find issues. This is particularly important for 
safety of flight applications. Vendors tend to perform the minimum amount of lab testing needed to 
ensure that the unit meets contract specifications. Vendors may not consider flight testing to be valid if 
they do not trust the source of truth vectors. 

Testing should also involve any hardware and software that interfaces with the unit. Thorough off-line 
testing of the unit and proposed algorithms that will interface with it should be performed before 
committing to specific integration architecture. Once the integration has been performed, thorough 
testing of navigation unit interaction with the rest of the avionics system is needed. 
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Early testing of the X-38 SIGI and knowledge of CRV trajectory requirements enabled the cold start 
attitude determination issue to be caught early, providing time to analyze the issue and develop an 
alternate procedure using digital video cameras (see Chapter 10, page 93). 

Allocate Sufficient Resources And Schedule For Testing 

Software issues tend to be discovered sequentially. Units containing complex software may not manifest 
anomalies in the initial round of ground and flight tests. This can lead to a false sense of security about 
the maturity of a software version. Enough rigorous ground and flight testing must be planned to 
thoroughly exercise the software. Schedule and budget should include interim software versions to 
allow issues to be discovered and resolved before a production software load is scheduled for 
certification. A lack of comprehensive, end-to-end testing has resulted in a number of spacecraft failures 
[9,57]. 

Adequate time and personnel must be set aside to analyze flight and ground test data. If data is not 
thoroughly analyzed in a timely manner, software issues will go unnoticed. Lack of resources can even 
lead to failure to analyze test data. Performance issues arising late in the development and certification 
cycle can negatively impact cost and schedule. 

Produce, Test and Fly I nterim Software Versions 

GPS receivers tend to become more robust after use in multiple applications has allowed users to identify 
and fix software anomalies. Some anomalies may not be fixed, as a previous user has judged them to be 
of no impact to the application in question. However, these issues may be an impact to a subsequent user 
of the same device. Introduction of a GPS receiver into a new operating environment (such as going 
from an aircraft to a spacecraft, or from a low Earth orbit application to a higher orbital altitude) can lead 
to manifestation of software issues not seen before. Differences in flight duration (aviation versus orbit, 
hours versus days or weeks) can also determine which software issues will manifest. For orbital 
applications, lab tests that subject a receiver to orbital dynamics for days or weeks should be considered. 

Interim software versions and multiple fly/fix/fly cycles (Table 1, page 21) were instrumental in resolving 
Shuttle MAGR/S performance and Shuttle flight computer issues, and built confidence in the system 
prior to certification for operational use in a safety critical application. From September 1996 to February 
2003, over 7,000 hours of "nominal performance" MAGR/S operating time was accumulated during 
Shuttle missions. The parallel integration architecture enabled the receiver to be flown in the actual 
dynamic and radio-frequency flight environment in a test mode, while interfaced with Shuttle flight 
computers [1]. 

I nstrumentation Port Data Is Needed During Flight and Ground Tests 

Instrumentation port data provides invaluable insight into software behavior during periods of 
questionable performance. Vendor input should be solicited concerning what data to collect and how it 
should be interpreted. Instrumentation port data simplifies and speeds up the identification of software 
problems. Software on data collection platforms (such as laptop computers) must be fully tested. 
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documented and certified. Clear and accurate procedures for laptop operation and troubleshooting are 
needed. Otherwise, it may be difficult to distinguish GPS receiver problems from problems with the data 
collection computer. Lack of instrumentation port data will lengthen the time needed to resolve a 
software anomaly, and may even prevent its resolution. Due to the June 1998 GPS receiver and Shuttle 
software anomalies on STS-91, a laptop computer was flown on many subsequent missions to collect 
instrumentation port data. 

Conduct Enough Test Flights Before Making Critical Decisions 

Initial flights of the 3M receiver (pre-production MAGR, Table 1, page 21, see also Chapter 7, page 57) 
were very successful. Later flights of the MAGR/S, along with ground testing and software audits, 
uncovered many issues that had to be resolved before the MAGR/S could be certified for TACAN 
replacement. It is important not to be lulled into thinking problems are not out there based on a small 
number of initial, successful test flights. Numerous software issues were discovered during the STS-91 
flight in June of 1998, resulting in a three-year delay of MAGR/S certification for operational use. 
However, the three TACAN units had already been removed from the orbiter Atlantis and three MAGR/S 
had been installed. The Shuttle Program had to remove three string MAGR/S and reinstall three string 
TACAN in Atlantis. 

Maintain Configuration Control Over Test Equipment And Procedures 

Perceived anomalous navigation unit performance in the lab is more likely to be caused by improper test 
equipment configuration and improper procedures, rather than software or hardware problems in the 
receiver, signal generator, or GPS satellite problems. A lack of accurate, documented test procedures can 
make it difficult to duplicate questionable receiver performance in later tests. This lengthens the amount 
of time it takes to determine the cause of suspect behavior. When trying to diagnose questionable 
performance, an accurate record of what procedures were performed and the test equipment hardware 
and software configuration is invaluable. Software associated with lab simulations and data collection 
for both lab and flight test applications should be accurately documented and verified. A lack of 
laboratory configuration control and documented operating procedures can result in a failure to discern 
the difference between a unit problem, a test equipment problem, or a user error. 


Provide The Vendor With As Much Data As Possible 

Vendors often complain that users provide minimal data when a problem with a unit occurs. Devices 
containing software are complex computers whose performance depends on a variety of factors. For 
example, in the case of GPS, a plot illustrating questionable position and velocity performance is not 
enough to permit a vendor to diagnose the true cause of an alleged anomaly. The vendor should be 
provided with as much digital data as possible, particularly channel and tracking parameters. 
Information on antenna location, hardware configuration and the procedures that were executed is also 
helpful. Vendors are busy and receive large numbers of inquiries from the user community. Users who 
suspect that a unit is malfunctioning should make a thorough investigation to determine if the alleged 
performance is a user error before involving the vendor. 
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I ntegrated Teams 


Communicate Early, Communicate Often 

Participation by experienced personnel from various disciplines who possess sharp technical skills and 
are motivated by lessons learned from past projects can facilitate development of robust and realistic 
requirements, and enable issues to be noted early in the project. Open and unrestricted communication 
between all project participants (vendor, users, integrators, host vehicle systems specialists) is essential to 
ensure that robust and accurate requirements are developed, issues are noted, and issues are resolved in 
a timely fashion. Open communication creates a positive working environment and enables team 
members to become educated on issues raised by various parties. 

The success of the Mercury, Gemini, Apollo, Space Shuttle, and ISS spacecraft development and flight 
programs was in part due to the existence of integrated teams, which freely communicated across 
corporate and civil servant/contractor boundaries. All participants had access to requirements and 
source code for a variety of on-board and ground systems, leading to a good understanding of system 
requirements and technical difficulties. This access facilitated accurate communication and timely issue 
resolution. Furthermore, the Mercury, Gemini and Apollo spacecraft were not nearly as complex as the 
Space Shuttle, ISS (and future vehicles), and required a smaller number of specialists to design, test and 
understand the systems. The increasing complexity of aerospace vehicles requires more specialists to 
assess the impacts of technical issues and modifications, which in turn necessitates effective and accurate 
communication. However, an environment of effective communication can be difficult to maintain over 
the long term in a large program, as evidenced by the losses of Challenger and Columbia [59-61]. All four 
NASA JSC GPS projects demonstrated the need for a close working relationship between the integration, 
user, and vendor personnel. 

The success-oriented nature of project budgets and schedules sometimes restricts communication at the 
technical level. Little or no money will be saved by a success-oriented approach that limits 
communication in an attempt to save money. Multiple layers of contractors cut down on communication 
and should be avoided. Concern about keeping management and technical discussions within the scope 
of the contract are valid, but such concern should not restrict open discussion of issues that are within the 
scope of the contract. Frequent and open communication between personnel (technical and 
management) is the key to catching and resolving problems early, lowering risk to cost and schedule, and 
building positive working relationships among team members. Trying to obtain design information in 
the presence of firewalls wastes time and money. Knowledge of product design and operation should 
not be isolated to a select few. Integration engineers must have access to testing facilities and data so they 
can become familiar with box performance. 

Early MAGR/S project reviews focused on hardware modifications, with little attention paid to software. 
Most technical personnel were "fire walled" from the software missionization process and the vendor. 
No formal, program wide reviews of the GPS receiver software modifications were made. The GPS 
vendor and the Shuttle navigation (both operational and engineering, contractor and civil servant) 
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personnel had minimal involvement in the missionization decisions made by the integrator. As a result 
of the GPS receiver and Shuttle flight computer anomalies that surfaced during STS-91, the GPS vendor 
was more fully integrated into the GPS project to enhance communication. Weekly teleconferences were 
established that included the vendor and all NASA and contractor organizations. Face to face meetings 
of all project participants were held at the Johnson Space Center three to four times a year. Special teams 
that crossed civil servant and contractor boundaries were formed to address specific technical and project 
management challenges. 

The Role of the User 

Users of the GPS receiver should be integrated into the project from the start, and work alongside 
development, integration, and vendor personnel. The user brings an operational and procedural 
perspective to the project. User input into the requirements process may prevent technical and 
procedural issues from arising after the operations phase has begun. Such issues may drive complicated 
and time-consuming work-arounds, analysis, and new software development. Receiver and systems 
requirements that reflect user considerations are a key to reducing life cycle costs once the operations 
phase has begun. 

Personnel from the JSC Missions Operations Directorate (MOD), responsible for Mission Control 
activities, mission design and planning, procedure and flight rules development, and astronaut training, 
were closely involved in the MAGR/S integration effort. MOD personnel participated in evaluation of 
MAGR/S flight test data, development of performance requirements, development of software and crew 
display requirements, anomaly investigation and anomaly resolution. User involvement throughout the 
MAGR/S project was later credited as a factor in the project success, in spite of numerous technical 
challenges. Early user involvement in the MAGR/S project was also a factor in the success of the later 
Shuttle SPOT project. 

Vendor I nvolvement 

Use of software intensive products in high-visibility, high-risk, and safety-related applications requires a 
higher level of vendor participation than other applications. Unfortunately, many vendors have little or 
no insight into how their products are integrated and used. Due to communication constraints imposed 
by success oriented budgets and schedules, vendors are frequently not involved in the definition of 
integration and software requirements. The "throw a unit and an Interface Control Document over the 
fence" approach can lead to cost and schedule problems. Vendor participation throughout the 
integration, test and certification program is invaluable, particularly if the receiver is used in an 
application for which it was not originally designed. The vendor possesses insight into receiver 
operation and design that is useful throughout a project. Vendor assistance in host vehicle systems and 
test requirements definition, receiver and integrated system anomaly resolution, procedure development, 
and data analysis can reduce risk to cost and schedule over the life of a project. Vendor support is more 
effective if they are provided with as much data as possible, along with test and flight equipment 
configurations and procedures that were executed. Vendor personnel should be given opportunities to 
learn about the application, as it may be different from previous applications of the receiver. This 


36 of 118 



knowledge may be useful in avoiding surprises due to use of a receiver in an application that it was not 
originally required to operate in. Fixed price contracts may limit or even prevent vendor participation. 
Such contracts pose high risk to cost and schedule. If the receiver vendor is a subcontractor to a 
navigation unit integrator, contracts should be written and budget provided to ensure that the vendor is 
accessible. 

What the Vendor Brings to the Table — Vendors possess valuable insight into a product through their 
knowledge of the product; it's original design requirements, and experience from previous applications 
of the technology. The vendor can be invaluable in reducing technical, cost and schedule risk by 
providing assistance in areas such as addressing anomalies, resolving questions over technology 
application, defining requirements (software, hardware, testing, integration). Technical interchange 
between both the vendor and user is required for risk mitigation. Early vendor participation in 
discussions on integration and architecture should be sought. The vendor can provide sage advice based 
on a detailed knowledge of unit operation. The vendor may also identify concerns related to the use of 
the product in a new environment. New (i.e. the product was not originally designed for the 
application), high risk, high visibility and safety critical integrations require more vendor involvement 
than other projects. 

Budget for Access to the Vendor — The GPS receiver is a critical part of the SIGI. Unfortunately, due to cost 
and schedule concerns, the user and SIGI manufacturer often had little or no opportunity to interact with 
the GPS vendors in the Shuttle, ISS and CRV SIGI projects. This made identification and resolution of 
GPS performance issues difficult. Contracts concerning integrated units should be written so that 
vendors of critical, software intensive components can be involved and able to give advice and 
information to the unit manufacturer, the integrator and the user. 

The Vendor and the Shuttle GPS Project — In hindsight, some aspects of the Shuttle GPS integration might 
have been done differently had the vendor been involved earlier in the project. The Shuttle software that 
interfaced with the MAGR/S was designed with an inadequate understanding of the software behind the 
interface definition. This lack of receiver insight was one of the causes of the problems encountered on 
STS-91. Initially, contact with the MAGR/S vendor was limited to a small group of personnel. 
Information obtained from the vendor was not passed on to other project participants, and the vendor 
was not consulted enough on integration and performance issues. After STS-91 the MAGR/S vendor was 
fully integrated into the GPS project team. Regular face-to-face contact between the vendor and Shuttle 
engineers built positive personal relationships and established a team rather than an adversarial 
environment. Both the vendor and Shuttle Program engineers became familiar with each other's work 
cultures, which enabled them to work better together and provide appropriate support to each other. 
Interaction with project participants during weekly teleconferences and face-to-face meetings enabled the 
vendor to understand concerns and various points of view expressed by project members, enabling them 
to propose solutions that were agreeable to all parties. The vendor also provided much needed 
education to Shuttle engineers concerning the challenges of GPS receiver design and operation. 
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Enable The Vendor to Learn About Your Application — While vendors have valuable knowledge about unit 
design, operation and performance in various applications, they may not fully understand the 
implications of using their product in a new environment. Vendor understanding of the new application 
environment and user requirements is necessary to enable the vendor to supply the best possible support. 
In the case of the Shuttle GPS project, vendor interaction with Shuttle personnel enabled them to 
ascertain how the Space Shuttle application differed from aviation users of their product. Observing 
Shuttle ascent and entry from Mission Control, flying landings in a Shuttle simulator, and participating in 
MAGR/S testing at Space Shuttle Program facilities enabled the vendor to become familiar with the 
Shuttle flight regime, crew and Mission Control procedures, flight rules, and aspects of Shuttle mission 
design. This facilitated better understanding of customer concerns and helped them identify 
improvements to be made to the receiver. The vendor provided advice that improved ground and flight¬ 
testing, issue identification, and issue resolution. The vendor also became familiar with the strengths and 
weaknesses of Shuttle Program GPS simulation facilities. This enabled them to provide input to Shuttle 
integration engineers concerning how best to perform receiver testing and verify functionality. 


The Challenge Of Being A New User 

In the mid 1990s, telemetry constraints and a complex ISS software requirements process prevented 
orbital debris avoidance needs from being addressed in ISS GPS telemetry requirements definition. The 
ISS SPOT application was not conceived for several more years. Likewise, the use of MAGR/S data for 
the Shuttle SPOT application was not identified until about three years after flights of the MAGR/S and 
associated Shuttle computer software had begun. However, the development and testing of the Shuttle 
SPOT application encountered far fewer technical difficulties than the ISS SPOT application. This was 
due to the differences between the development and test phases of the two projects. 

The safety-critical MAGR/S project enjoyed extensive, full system testing in both laboratories and the 
flight environment. Associated Shuttle software and telemetry requirements were exhaustively reviewed 
by all project participants (civil servant and contractor, engineering personnel. Mission Control and 
mission design personnel) before the initiation of MAGR/S test flights on the Shuttle. Furthermore, SPOT 
processing of MAGR/S data for development purposes did not begin until several interim receiver 
software versions had been produced and test flown. Vendor involvement ensured that project 
participants understood MAGR/S data and operating characteristics. MAGR/S software, originally 
developed at government expense, had been made available to the Shuttle Program and was undergoing 
an audit by the NASA IV&V contractor. This also ensured that receiver performance and operation was 
well understood. While the MAGR/S was not ready for certification to support Shuttle TACAN 
replacement, it had undergone enough testing to avoid major technical surprises during the Shuttle SPOT 
development process. 

New uses for GPS receiver data will most likely be identified that were not anticipated when the initial 
spacecraft GPS and overall system requirements were written. Requirements for components in the 
integrated system (GPS receivers, interfacing on-board avionics, on-board and ground telemetry 
processing) may not meet the needs of the new user. Furthermore, systems integrators, software process 
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owners and operations personnel may not initially recognize the new user as a customer for the data. 
This may make it difficult to get priority and support for resolving issues, identifying requirements and 
software changes, and getting changes approved and implemented. While it is not possible to forecast 
with 100% accuracy what new uses for receiver data on a particular spacecraft may come up in the future, 
experienced personnel should make an effort to identify output data and telemetry requirements that will 
avoid problems experienced with past integrations. New users of GPS data may experience difficulty in 
elevating concerns through unfamiliar, poorly defined, and/or complicated software and hardware 
configuration control processes that encompass multiple on-board and ground systems. 


Documentation 

A lack of configuration-controlled documentation can lead to incorrect knowledge about receiver or 
signal generator design, operation and performance. Inadequate understanding of unit design and 
operation can also lead to misinterpretation of test results. This makes problem resolution more 
expensive. A lack of accurate, detailed product documentation forces integrators to spend significant 
amounts of lab time trying to get the unit to work properly. Frequent consultations with the vendor 
drives up project costs. 

Keep Accurate Records 

Detailed and accurate records of meetings, issues and issue disposition, design rationale, and testing 
results should be maintained. This enables project participants to be better informed on issues facing the 
project and provides a record for the future. An official issue list should be maintained, along with a list 
of questions for the vendor and vendor responses. Issue and question status and closure should be 
recorded and periodically reviewed. 

I dentify And Resolve Legal I ssues Concerning Proprietary Documentation 

If a device contains proprietary software, legal arrangements must be made to permit inspection of 
proprietary documentation. Lack of access to proprietary documents can result in undetected issues. 
One such example was the telemetry bandwidth problem on the European Space Agency 
Cassini/Huygens Titan probe. Telemetry requirements for the Huygens data receiver on Cassini did not 
include the effects of Doppler shift. This issue was not discovered until a communications test was 
performed while the probe was enroute to Saturn [42]. To compensate for the error, the trajectory was 
changed to minimize the Doppler shift between Cassini and Huygens. This slipped the Huygens arrival 
at Titan from November 2004 to January 2005. Factors that contributed to the late discovery of the 
problem were lack of access to proprietary documentation, no end-to-end system testing and a lack of 
comprehensive project requirements. 
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I nterface Control Documentation (ICD) 


If the integrator and user do not have access to software and software requirements, the ICD may be the 
only written source of information on unit parameters. Developers of software that will interface with 
the unit must examine the ICD closely. The ICD and the interfacing software must be compared to each 
other throughout a project. The ICD should also be compared to ground and test results to ensure that it 
accurately reflects unit input, output and operation. An inaccurate ICD will lead to software and 
procedural issues that will have to be addressed before a system can be certified as operational. An 
accurate ICD is also needed for any data available in the lab (i.e. instrumentation port data) that might 
not be available once the unit is integrated into an operational system. This is critical in the test and 
verification phase of a project. 

Integrators should strive to understand operation of the software intensive devices as much as possible 
before defining requirements for code that will perform interface functions. Interfaces should be bullet 
proofed since it may not be possible to account for all forms of anomalous unit behavior. 

Short development schedules may result in changes to the ICD while host vehicle software requirements 
are being defined and software is in development and test. A disciplined process of checks must be in 
place to ensure that the ICD and software requirements for units that interface with each other are 
consistent. Individuals who are knowledgeable in requirements for various interfacing units must be 
able to communicate and be involved in any changes made to the ICD. 


Design I nsight 

Design insight is required for high-risk, safety-related applications for the COTS integration to be 
successful. Users of COTS units usually have little or no insight into software design, design rationale, 
and operation. Available documentation may not contain accurate, pertinent information that would aid 
an integrator in designing integration architecture, defining interface and software requirements, test and 
operational procedures, and issue identification and resolution. A vendor supplied Interface Control 
Document may not contain enough information to permit host system interface software requirements 
creation. Many devices, such as GPS receivers, contain legacy code, some of which may be one or more 
decades old. Vendor engineers may not have participated in the original development of the product. 
Over time, corporate knowledge loss concerning design rationale occurs due to retirements, employee 
attrition, office clean-ups, and corporate takeovers. This will make it difficult for the vendor to answer 
integrator and user questions. Vendor answers to questions may be limited to "how" a device operates, 
but not "why" it was designed to operate that way. If a vendor is not forthcoming concerning design 
insight, consultants and other users of the product may be able to provide information. 

As much design information as can be obtained is invaluable for determining if a device is really suitable 
for an application, and what hardware and software modifications are required for it to meet 
requirements. Lack of design insight makes this determination difficult. Issue identification, issue 
resolution and procedure development are also hindered by lack of design insight. Excessive amounts of 
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proprietary documentation and software also hinder the process, even if proprietary non-disclosure 
agreements are in effect. This can result in identification of serious technical issues late in the 
development and test program, or after operational use has begun. Lack of design insight can lead users 
to attribute suspect performance to the unit or some other component of an integrated system, when the 
real problem is a lack of user understanding of the device and how it should be operated. During a space 
mission, operators of both unmanned and manned spacecraft live by their data. Wrong information 
about system functionality can lead to making the wrong decisions when faced with a spacecraft 
anomaly. This can lead to loss of data, some vehicle capabilities [50] or even the spacecraft itself, as in the 
1997 Lewis satellite incident [45]. Some form of knowledge capture and management should be 
implemented by developers, users and integrators to ensure preservation of system knowledge that is 
critical for resolving issues and examining proposed reuse of software and hardware in new 
applications.* 

The ISS Experience With SI Gl Design I nsight 

The developers of the original Force 19 attitude determination software were not permitted to see the 
Force 19 code that the attitude software would interface with, as it was proprietary. Furthermore, NASA 
JSC and contractor personnel responsible for integrating the SIGI into the ISS avionics system were not 
permitted to see the attitude determination code, as it was also classified as proprietary. These 
restrictions complicated SIGI flight qualification, as well as resolution of SIGI issues once the units were 
operating on the ISS. This experience was one factor in the decision to develop and maintain a new set of 
non-proprietary attitude determination code owned by NASA (see Chapter 6, page 49). 

The Shuttle Experience With MAGR/ S Design I nsight 

For a flight critical application (i.e., the box is required to safely conclude the mission), a box will undergo 
more modification than in other applications. The user will also require more detailed knowledge of 
navigation unit design and operation than users of non-safety critical units. The Shuttle Program 
considers a box to be failed more quickly than an aviation user. Engineering and Mission Control 
personnel must have a thorough understanding of receiver operation and data. For manned space flight, 
lack of design insight is a safety issue. Due to the anomalies that occurred on STS-91, MAGR/S software 
requirements, the integration guide and source code (originally developed at government expense) were 
made available to the Shuttle Program. A formal "questions for the vendor" list was maintained and 
answers were recorded. 

The STS-91 incident revealed that the Shuttle computer software that interfaced with the MAGR/S was 
designed with an inadequate understanding of MAGR/S operation. The Shuttle software was later 
modified to handle known and unknown receiver anomalies. Expanded vendor involvement after STS- 
91 brought much needed design insight to the project, which greatly aided issue identification and 
resolution. In hindsight, some aspects of the MAGR/S interface and integration might have been done 
differently if the vendor had been involved when the Shuttle computer software requirements to support 
GPS were initially defined. 

* John L. Goodman, Knoioledge Capture and Management for Space Flight Systems, NASA Contractor Report 
CR-2005-213692, October 2005. Available at http://ntrs.nasa.gov/ 
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Insight into test equipment design and operation is critical. Like vendors of GPS receivers, vendors of 
test equipment may not understand the applications that their equipment supports. Many issues that 
arose during MAGR/S ground testing concerned GPS signal generators. These issues had an impact on 
test results, cost, and schedule. Insight into GPS signal generator design and operation was a challenge 
throughout the project. 

I mpact of Design I nsight on Science Missions 

Little or inaccurate design insight can complicate or prevent the use of GPS data in support of GPS 
technology demonstrations and scientific missions. Examples of this include GPS technology 
demonstration payloads flown on the Shuttle. During the relative GPS experiments conducted on STS-69 
and STS-80, lack of insight into the 3M, TurboStar, Tensor and Quadrex receivers made integration, data 
processing and data analysis more difficult. In addition, lack of insight into algorithms (particularly 
those associated with clock steering) made development of the laptop based relative GPS navigation filter 
more challenging [12-15]. 


I ndependent Verification And Validation 

If it can be afforded. Independent Verification And Validation (IV&V) is a valuable part of a high risk or 
safety critical project. Verification is the determination of whether or not an item meets the requirements 
set for it. Validation is the determination of whether or not an item meets its intended purpose in its 
operating environment. Validation is particularly important when an item or new technology is to be 
used in an operating environment that it was not originally designed for. The trend to use non- 
developmental item avionics containing proprietary software may prevent IV&V of software in some 
safety critical applications. This is an issue for applications that involve human safety and unmanned 
applications requiring a high degree of autonomy. 

IV&V of software requirements and source code may reveal issues that did not arise during lab and 
flight-testing. Guidelines should be created governing the scope of the audit. Issues should be examined 
to determine if they represent credible failure scenarios. 

The NASA IV&V contractor played a significant role in the MAGR/S project [62-66]. Initial IV&V 
involvement focused on the integration architecture, ground test, and flight test results. After MAGR/S 
certification was postponed in the wake of the STS-91 incident (1998) and MAGR/S software (originally 
developed for the Department of Defense at government expense) was made available to the Shuttle 
Program, IV&V performed an audit of the software starting in 1999. IV&V personnel possessed prior 
experience with the MAGR on aircraft integrations. The IV&V contractor played a valuable role in 
identifying, assessing the criticality of, and assisting with the resolution of software issues. The audit was 
invaluable in the certification process, but should have been conducted much earlier in the project. 
Several hundred issues, of varying degrees of severity, were identified and dispositioned through the 
IV&V analysis of the MAGR/S requirements and software. 
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Orbit Determination Accuracy 


While accuracy of COTS navigation units may be sufficient in some cases to support low accuracy space 
flight requirements. Shuttle flights of these units indicate that they are not appropriate for future 
applications with more demanding orbit determination needs. 

Formation flying, elimination of ground tracking and orbital replenishment (rendezvous, proximity 
operations and docking) will place stringent demands on orbit determination and relative navigation 
accuracy [67]. Software quality, hardware reliability and orbit determination accuracy requirements to 
support these applications will be more demanding than the capabilities of current GPS units. 
Autonomous, on-board, real time navigation, relative navigation and bum targeting requires investment 
in spacecraft navigation systems that will differ from atmospheric flight navigation systems. 

Velocity Accuracy I s I mportant 

Targeting algorithms that compute precise orbital adjustments to support activities such as (but not 
limited to) formation flying, rendezvous, proximity operations and docking/grapple need accurate 
velocity as well as position. Such algorithms have to predict vehicle state vectors into the future over a 
period of time that may range from minutes to weeks. Even small velocity errors can result in large 
position and velocity errors after a prediction using high fidelity integrators and environment models. 
How well a navigation unit state vector predicts into the future is a key question that potential users of a 
unit must ask and address during flight and lab test evaluation. 

Orbital Semi-Major Axis 

A metric used to evaluate how well a state vector will predict is the semi-major axis [68] accuracy. 
Orbital semi-major axis is a function of position, velocity and energy (1). It is also related to the period of 
the orbit (2). 
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Relative semi-major axis accuracy is a good parameter for judging the accuracy of a relative GPS 
algorithm for formation flying and rendezvous applications. 


A recent journal article addresses the importance of semi-major axis accuracy and the need for realistic 
correlation between position and velocity [23]. This article was written in response to the poor 
navigation performance observed on Shuttle flights of off-the-shelf GPS receivers and EGIs. 
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Most Space Navigation Conference Papers Do Not Address High Accuracy Orbit 
Determination 

Some papers appearing in the literature advocate geometrical, kinematic type position-determination 
techniques using GPS data. The advent of all-in-view receivers supports this trend. Such algorithms take 
advantage of continuous, high rate GPS measurements and the improved measurement geometry 
compared to ground based radar tracking. From a software perspective, these algorithms are more 
straightforward since complex environment models (such as gravity and drag) are not used. While the 
position and time data resulting from kinematic positioning algorithms are very accurate and meet the 
requirements of some missions, this solves only half the problem for other users. 

Many papers discuss a range of space applications of GPS and the high-position accuracy it offers, but 
pay little or no attention to the need for accurate velocity and semi-major axis estimation. Numerical 
results of algorithms designed to improve spacecraft navigation accuracy are exclusively focused on 
position accuracy, with no mention of velocity and semi-major axis errors. Challenges in spacebome 
applications of GPS are often detailed, such as: 

• Widening the Doppler shift window. 

• Installing an orbit propagator to facilitate reacquisition after a GPS outage. 

• Multipath 

• GPS satellite visibility as a function of spacecraft attitude. 

• GPS satellite visibility to antennas on spinning spacecraft. 

• Increased number of satellites visible on-orbit. 

• Satellite visibility and signal strength for geostationary satellite applications. 

• Modifying legacy navigation algorithms to accommodate higher orbital altitudes and velocities. 

However, the need to improve navigation and filtering algorithms to enhance velocity and semi-major 
axis accuracy is rarely mentioned. Lack of orbital and relative semi-major axis accuracy data, along with 
position and velocity correlation data, make it difficult to evaluate the usefulness of relative GPS 
navigation studies and algorithms published in the literature. Such data is required to assess navigation 
accuracy impacts on targeting and guidance algorithms and perform propellant budgeting. 

Receiver Specifications 

Receivers have specifications for expected position and velocity accuracy under the best tracking 
conditions. Even receivers designed for space lack a semi-major axis specification. This, coupled with 
the proprietary nature of receiver software, makes it difficult for potential users to determine how 
suitable a receiver may be for a space application. 

Navigation units that are needed to support advanced concepts (formation flying, rendezvous, 
autonomous operation, limited ground support and infrastructure) require navigation algorithms that 
reflect orbital mechanics. While it is true that position, velocity and orbital parameter accuracy 
requirements vary from program to program, this should not be used to justify a lack of appropriate 
navigation algorithm missionization. 
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COTS Box Outputs May Not Be Designed With Redundancy Management I n 
Mind 


Most aircraft and missiles use only one GPS receiver, stand-alone Inertial Navigation System (INS) or 
Embedded GPS/INS (EGI). Some vehicles (Space Shuttle, ISS, X-33, X-38) were designed to use multiple 
navigation units for redundancy. Redundancy Management (RM) schemes perform checks on box 
outputs, such as dynamic parameters (position, velocity, attitude, rotational rate and accumulated sensed 
velocity) and health status parameters (Built-In Test/Built-in Test Equipment, BIT/BITE). Most BIT/BITE 
indicators and self-tests were designed to help ground personnel determine if a suspect unit should be 
returned to the depot for maintenance. 

Use of BIT/BITE indicators in RM algorithms requires that the integrator understand what the health 
status indicators mean and how indications of a problem can affect navigation unit performance. Care 
must be taken when determining which parameters to monitor for assessing unit health. A title of what 
the indicator is in an interface control document does not tell the integrator the potential impact the 
annunciated condition has on box performance. This makes it difficult for the integrator to determine 
which BIT/BITE indications should be used in the RM algorithm. The RM scheme should be robust 
enough to identify and deselect a questionable unit but not deselect a good unit. BIT/BITE indicators in 
navigation units evolve over long periods and have a heritage going back decades to previous products. 
Particular indicators are often added to help address certain problems encountered. Over the years, 
corporate knowledge loss results in a manufacturer no longer knowing why a particular indicator is 
present in the output or what its significance is. Of particular importance are what values performance 
indicators (such as Figure of Merit) are initialized to after a unit power cycle or re-initialization. 

Unlike aircraft, the Space Shuttle performs BIT on navigation units during flight. Mission Control must 
understand how to interpret negative results. Does a certain failure indication from BIT always mean 
that the unit should not be used? Could the unit continue to be used for navigation with no degradation 
in performance? Nuisance indicators need to be identified and ignored. A BITE masking capability is 
particularly useful. 

While redundancy management is important, it is not a substitute for well-documented and fully verified 
software. 


Do Not Totally Rely On The Vendor For Navigation Expertise 

Vendors can provide valuable information on the design, integration, and use of their products. 
However, they may not always fully understand the applications where their products are used. Users 
and integrators must maintain navigation expertise to conduct testing, resolve issues, avoid "false pulls" 
of healthy units that are assumed to be malfunctioning [69], determine how best to integrate a unit, and 
provide management with advice on what navigation products are suitable for an upgrade. Navigation 
vendors, who are doing business in a highly competitive market, do not want skilled technical personnel 
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tied to one project for periods of years. The use of a COTS navigation product should not lead one to 
believe that technical expertise can be "bought" as a COTS product. 


Vulnerability to Space Radiation 

Each succeeding generation of electronic devices, such as GPS receivers, use smaller and smaller 
electronic components. This may make modern GPS receivers more susceptible to space radiation upsets 
than the legacy receivers. The higher susceptibility of new receivers to radiation makes use of GPS prior 
to and during safety-critical flight phases (such as deorbit) questionable. A modern receiver may require 
expensive modification to meet reliability requirements, or the required reliability may have to be 
lowered. 


The Challenge Of Autonomous, On-Board Navigation 

Autonomous operation of spacecraft systems has long been a desire to reduce operations costs. 
However, such a requirement poses high reliability requirements on system components. Software safety 
is an important consideration in any aerospace system [9, 40, 57]. 

Rather than being viewed as off-the-shelf, plug-and-play units, GPS receivers are complex computers that 
interact with other complex computers. The GPS and host vehicle computer incidents on Discovery 
(June 1998) and ISS (September 2002) illustrate that GPS receivers and host vehicle computer systems can 
interact in a dysfunctional manner with results that are vehicle wide and not anticipated. Even a GPS 
receiver in non-safety-critical functions could threaten safety of flight by affecting safety critical systems 
such as flight computers and communications systems. Non-safety-critical receivers may require an 
extensive testing and certification process for an autonomous application, or the host vehicle avionics 
system must be robust enough to survive known and postulated dysfunctional interaction between 
system components, and recover to a safe state. 

Roadblocks to achieving on-board navigation autonomy include on-board system capacity, cost, schedule 
and technical complexity. Trade-studies may have to be conducted to determine the level of autonomy 
that is commensurate with maturity of the technology, on-board system capacity, and available schedule 
and budget. If the available GPS receivers do not meet orbit determination requirements as built, the 
chosen receiver will either have to be modified, or additional orbit determination software placed on the 
spacecraft. The orbit determination function may even have to be performed on the ground. 

One example of a trade-off between on-board complexity and autonomy is the Swedish Space 
Corporation Odin aeronomy satellite, which is equipped with two GPS receivers. To reduce on-board 
complexity, it was decided to perform precision orbit determination on the ground using down linked 
GPS data, rather than on the satellite. The receivers require periodic re-initializations, and commands are 
sent from the ground to accomplish this [70]. 
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It is important to carefully assess the maturity of a technology, even if there is potential that the 
technology could enable autonomy and reduce development, integration, and life cycle costs. A proven, 
but initially more expensive solution, may save money in the long run. 


Navigation Conferences 

Receiver reliability and robustness is seldom addressed at navigation conferences. Reports on new GNSS 
applications and integrations rarely highlight the more mundane process problems that were 
encountered when implementing and using GNSS technology. Problems with hardware and software 
procurement, software quality, lack of information on receiver design and operation, poor 
communication between project participants, poor vendor support, cost and schedule problems, test 
equipment issues, and inaccurate documentation are rarely mentioned in papers or keynote speeches, but 
are often discussed informally by technical personnel outside conference forums. Vendor feedback to the 
user community is often missing. The tendency to avoid mentioning problems makes it difficult, if not 
impossible, for GNSS integrators and users to learn how other users and integrators overcame process 
challenges to bring a project to a successful conclusion. 

Conference agendas should include lessons learned sessions that facilitate discussion among users and 
integrators. Best practices cannot be identified and communicated if problems and their solutions are not 
discussed. There should be a willingness to discuss negative aspects of projects, including project 
failures, while sticking to the facts and not assigning blame to individuals or organizations. A vendor 
feedback session, featuring a panel of vendor representatives, may allow users and integrators to become 
aware of common problems observed by vendors from having worked with a large customer base. 
Vendor comments should not be limited to perceived obstacles to selling their products. Tutorials on 
process engineering (i.e., software development, testing, certification, device selection, integration, project 
management) as applied to the navigation industry may be helpful to conference participants. 
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6.1 nternational Space Station 


In 1993, GPS was chosen over star trackers for ISS attitude determination. Although star trackers had a 
high state of technology readiness, it was believed that use of GPS for attitude determination would 
lower development and integration costs. GPS position, velocity, and time would be used by the ISS as 

well. 


ISS Space I integrated GPS/1 NS 

The Space Integrated GPS/Inertial Navigation System (SIGI) was a project to develop a common 
spacecraft navigator for both manned and unmanned vehicles [2, 3, 71]. The Force 19 GPS receiver in the 
SIGI was specifically developed for the ISS application. The Force 19 attitude determination software 
was developed by NASA and furnished to the GPS vendor as Government Furnished Equipment (GFE). 
The ISS SIGI came equipped with a strapdown Inertial Measurement Unit, although at the time there was 
no ISS requirement for the strapdown accelerometer and ring laser gyro data. Blended filter data from 
the SIGI is not used. Two SIGI units are located in the U.S. laboratory module Destiny. Four GPS 
antennas, each equipped with choke rings for multi-path mitigation, are at the corners of a 1.5 by 3 meter 
rectangle on the SO truss (Figures 1 and 2) [2]. 



Figure 1 - One of the four ISS GPS antenna and choke 
ring assemblies prior to launch. The assembly is 10.81 
inches wide. 


A Kalman filter was implemented in the SIGI for position and velocity determination in the presence of 
Selective Availability (SA). However, the deactivation of SA and technical issues with the filter has 
driven the ISS Program to rely on the deterministic position and velocity solution from the Force 19. 


One hundred foot long cables connect the antenna assemblies to the SIGI units. Double differencing was 
used to cancel out cable biases than could not be determined before the hardware was brought to the ISS. 
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Figure 2 - Close up of ISS GPS antenna array location. This photograph was taken on STS-111 
following undocking over western Kazakhstan on June 15, 2002. Endeavour was conducting a fly- 
around of the ISS. The docking port is pointed along the velocity vector. 


Most of the attitudes flown by the ISS do not allow the GPS antenna boresights to be pointed along the 
zenith direction [72, 73]. ISS SIGIs are provided with antenna pointing information to facilitate satellite 
acquisition. 
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Ground Testing and Shuttle Test Flights of ISS SI Gl 


Lab Tests 

An array of flight qualification tests were conducted in ground facilities, using both GPS signal 
generators and live sky antenna arrays. Complex mathematical models were developed and lab testing 
performed in an attempt to subject the SIGI to the multi-path rich ISS radio-frequency environment [2, 
74], However, lab testing could not exactly duplicate the ISS radio-frequency environment. 

Flight Tests 

Attitude determination algorithms used in the ISS SIGI were first tested in a TANS Vector GPS receiver 
flown on STS-77 ( Endeavour , May 1996, Table 3) as a part of the GPS Attitude and Navigation Experiment 
(GANE) [75, 76]. The GANE hardware was mounted in the payload bay. ISS SIGIs were flown for data 
collection in the SIGI Orbital Attitude Readiness (SOAR) experiment on two Shuttle missions, STS-101 
(Atlantis, May 2000) and STS-106 ( Atlantis , September 2000) to test position, velocity and attitude 
determination [77]. SOAR used much of the GANE hardware, and was also in the payload bay. Star 
trackers collocated with the SOAR hardware provided a check on Force 19 attitude determination. While 
these flights did provide valuable on-orbit data, they could not subject the SIGI to the exact multi-path 
and signal obscuration environment later encountered on ISS. 


SI Gl Flight Experience on the I SS 


The two SIGI units arrived at the ISS when the Destiny module was delivered on assembly flight 5A (STS- 
98, Atlantis, February 2001). GPS become operational on ISS after the SO truss was installed on assembly 
flight 8A (STS-110, Atlantis, April 2002). Actual use on the ISS was the first time the ISS SIGI was used 
during extended (longer than a Shuttle mission) flight. 


Table 3- Shuttle and Progress Missions Related to ISS SIGI 


Mission 

Year 

Spacecraft 

ISS GPS Objective 

Primary Mission Objectives 

77 

1996 

Endeavour 

GANE GPS attitude test 

SPARTAN deploy/retrieve, SPACEHAB 

101 (2A.2a) 

2000 

Atlantis 

SOAR SIGI testing 

ISS resupply and outfitting 

106 (2A.2b) 

2000 

Atlantis 

SOAR SIGI testing 

ISS resupply and outfitting 

98 (5A) 

2001 

Atlantis 

SIGI delivery to ISS 

Deliver Destiny lab module 

110 (8A) 

2002 

Atlantis 

GPS antenna array delivery 

Deliver SO truss & Mobile Transporter 

14P 

2004 

Progress M-49 

Deliver new SIGI software 

ISS replenishment. Docked 5/27/04 

15P 

2004 

Progress M-50 

Deliver SIGI loader cable 

ISS replenishment. Docked 8/14/04 
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Use of GPS by ISS 


Force 19 deterministic position and velocity data must pass quality assurance checks and a selection filter 
before they are incorporated into the ISS computer navigation solution. The Force 19 deterministic state 
vector must meet an orbit determination accuracy requirement of no greater than 1,000-foot three-sigma 
semi-major axis error to support Ku Band antenna pointing to TDRSS satellites. GPS attitude data is 
filtered in an ISS computer along with rate gyro data (not from the SIGI) to determine an attitude solution 
that meets the ISS 0.5-degree 3 sigma per axis attitude accuracy requirement. While the SIGI and the ISS 
attitude control system have met requirements for attitude, position, velocity, and time determination 
accuracy, numerous technical issues surfaced that impacted solution availability. Most of the issues were 
discovered after ISS SIGI operations began in April of 2002. Identification and recovery from many of 
these problems required Mission Control and astronaut/cosmonaut intervention, which added additional 
work to already complex ground and crew timelines. 

I mpact of One Force 19 I ssue 

On September 22, 2002, and again on the following day, a Force 19 software error not recognized in 
ground testing occurred that caused the SIGI to emit a type of output to the ISS Guidance, Navigation 
and Control (GNC) software that was not anticipated by system integrators. The output caused ISS GNC 
computers to go into a diagnostic mode, which resulted in the mission impacts listed in Table 4. It was 
known and documented that the ISS computer could not handle the output in question, but during the 
integration and test phase, no evidence was noted that any avionics would supply that type of output to 
the ISS computers. The SIGI units were turned off for several weeks, until a software patch was 
developed and applied to the ISS GNC software. The patch enabled ISS computers to handle the 
spurious output without interrupting normal operation. Subsequent emissions of the spurious output by 
the SIGIs were correctly handled by the ISS computers with no ill effects. 


Table 4 - Operational I mpacts of SI Gl I nduced I SS Computer Crash 

• Transfer of attitude control from the U.S. Segment control moment gyros to the Russian segment 
thruster system 

• Contingency attitude control using valuable and carefully managed propellant supplies 

• Labor intensive manual S band antenna pointing by MCC Houston to maintain data and voice 
communications 

• Loss of Ku band data transmission capability 

• Loss of micro-gravity environment due to attitude control thruster firings 

• Loss of a crew day of science operations 


52 of 118 




Solution Availability 


Another issue was limited solution availability. Due to non-optimal antenna pointing, signal obscuration, 
and the rich multi-path environment, the GPS attitude determination function frequently has to solve for 
integer ambiguities in carrier phase. Up to an hour may be spent solving for the ambiguities, and the 
receiver will not output a position and velocity during these periods, the time and duration of which are 
not predictable. This feature of the unit was known before use on-board the ISS began, and was judged 
not to be an impact to the ISS antenna-pointing requirement. However, it was an impact to ground 
processing of Force 19 data, which will be discussed in the next section. No requirement was levied on 
the unit for the maximum acceptable position, velocity or attitude outage. 


ISS Spacecraft Position Optimal Tracking (SPOT) Filter 

Why Filter GPS States? 

There were no requirements for the Force 19 to perform precision ISS orbit determination. Ground radar 
tracking of the ISS is only performed by Mission Control Houston to support Shuttle rendezvous. 
Although coherent S-Band TDRSS transponders are carried by the ISS, there are currently no plans to 
process TDRSS Doppler from ISS in Mission Control, as is done for the Shuttle. Historically, continuous 
tracking of the ISS by U. S. Strategic Command was the source of ISS orbit data used for ISS debris 
avoidance efforts and mission planning conducted by Mission Control Houston. A Mission Control 
based GPS ground filter (ISS SPOT), similar to the one developed for the Shuttle MAGR/S data, was 
developed to process Force 19 deterministic state vectors to provide high accuracy orbit determination to 
support collision avoidance, orbit maintenance, rendezvous planning, and to augment ground radar 
tracking in support of Shuttle rendezvous. 

Processing SI Gl Flight Test Data 

Force 19 deterministic state vector data from flights of the ISS and X-38 SIGIs on Shuttle missions STS-101 
SOAR (Table 3, page 51) and STS-108 (Table 1, page 21) were processed by the ISS SPOT filter during 
development. The flight data was useful in developing and tuning the filtering algorithms. However, 
these test flights did not provide insight into Force 19 performance in the radio-frequency environment of 
the ISS, nor was Force 19 data processed by ISS telemetry software. 

I SS SI Gl Data and SPOT 

Once the SIGI units were in operation aboard the ISS, Force 19 data was processed by the developmental 
version of the ISS SPOT filter. While the filter successfully performed orbit determination to a higher 
level of accuracy than the Force 19, data problems severely limited the time spans over which orbit 
determination could be performed. Frequent loss of integer ambiguity solutions prevented Force 19 
output of position and velocity estimates. Furthermore, much of the required data was not time 
homogeneous. Even if the Force 19 was computing position and velocity data, variations in ISS telemetry 
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format content and low SIGI data priorities prevented acquisition of the input required for the ISS SPOT 
filter. The frequent lack of Force 19 position and velocity vectors caused the SPOT filter to converge 
much more slowly, or even prevented orbit determination from occurring in the first place. Lack of a 
suitable and unambiguously defined Force 19 solution quality indicator complicated processing of Force 
19 data by SPOT. 

Most of the ISS SPOT development effort focused on a pre-processor to weed out unacceptable Force 19 
data before it reached the orbit determination filter. Development of the pre-processor required extensive 
analysis of SIGI data and complicated the software development process, resulting in schedule problems. 
ISS SPOT has been certified for flight use, and will provide improved orbit estimates for mission planning 
after a flight-following period in Mission Control. 


SI Gl Software and ISS Telemetry Changes 

Since April of 2002, SIGI performance has been continually assessed, and modifications to Force 19 
receiver and SIGI input/output software were identified, developed, tested, and flight qualified. In 
addition, a new set of attitude determination code was developed, tested, and flight qualified, which 
resolved many performance issues. Due to the grounding of the Shuttles following the Columbia accident, 
the new SIGI software and a laptop-to-SIGI software loader cable were sent to the ISS on two Progress 
flights (Table 3, page 51) launched from the Baikonur Cosmodrome. 

New Attitude Determination Software 

The NASA SIGI team at the Johnson Space Center developed the new code, which is government owned 
and maintained, whereas the original Force 19 attitude determination software was developed by a 
different NASA organization and became proprietary after delivery to the receiver vendor. The new 
attitude determination software used a different method of integer ambiguity resolution and attitude 
determination, which significantly increased attitude solution availability. 

In response to the software issues encountered with the original attitude determination code, the software 
development and testing process for the new code was significantly different. All attitude determination 
code and associated software development and testing tools were placed under strict configuration 
management. Coding standards were followed, code audits were performed, and modules were 
exhaustively tested on a workstation using both nominal and off-nominal input data. All lines of code 
and software paths were tested. Built-in error words were placed in the code, which greatly aided 
software anomaly analysis once the new attitude determination software was placed in the Force 19. In 
addition, all developmental software versions were meticulously documented and saved for future 
reference. The software and test cases were completely documented, and the theoretical development of 
and assumptions inherent in the new attitude determination algorithm were thoroughly documented. 
Since the new software is not vendor proprietary, NASA JSC SIGI and associated ISS contractor 
personnel have complete access to requirements, source code and theoretical development 
documentation. This greatly aids verification and anomaly investigation efforts. 
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Initialization data was placed in the new attitude determination software to lower the amount of work 
required by Mission Control personnel to recover the SIGI after a power cycle. The capability to adjust 
additional attitude determination algorithm parameters from Mission Control was also added. Solution 
of carrier phase integer ambiguities was decoupled from position and velocity determination, which 
resolved the extended position and velocity outage issue. 

New SI Gl and Force 19 Software 

Both the SIGI and Force 19 vendors resolved software and performance issues not associated with the 
attitude determination function. To improve ISS re-boost maneuver monitoring and post-bum orbit 
determination by Mission Control Centers in Moscow and Houston, the SIGI and ISS GNC software has 
been modified so that integrated acceleration from the SIGI strapdown IMUs can be incorporated into the 
ISS GNC processing and downlisted to the ground. 

ISS Telemetry Changes 

ISS SPOT developers identified several problems in Force 19 data that were due to ISS telemetry format 
and content. Several changes were made to telemetry requirements to ensure that the ISS SPOT input 
data would be grouped together in the same data packets, were time homogenous, and would be present 
in the telemetry stream when needed. 


Other GPS Receivers On The I SS 

For completeness, it should be pointed out that there are other GPS receivers on the ISS, which were not 
test flown on the Space Shuttle. Two ASN-2401 navigation systems, containing ASN-22 GPS/GLONASS 
GPS cards, are in the Russian built Zvezda Service Module [78]. They supply navigation data for the 
Russian segment of ISS. Two Laben Tensor units will also be carried on the European built Automated 
Transfer Vehicle (ATV) to support automated rendezvous, in conjunction with the ASN-2401 units on the 
Service Module. The ASN-2401 units will be upgraded to support relative navigation before the ATV 
flight operations begin. Two SIGIs will be on the Japanese Experiment Module (JEM) and three on the 
Japanese Transfer Vehicle (HTV) to support rendezvous. The SIGIs contain Trimble Force 5 GPS cards. 
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7. The Space Shuttle and GPS 


In the 1970s, the Space Shuttle was designed with three TACAN units for use during the entry phase of 
flight. By the late 1970s, with the NAVSTAR GPS program promising a revolution in navigation, the use 
of GPS on the Shuttle orbiters was studied [79]. The orbiters Discovery, Atlantis and Endeavour were all 
manufactured in the 1980s with GPS antennae and associated wiring. However, due to budget concerns 
and the developmental nature of GPS, a GPS upgrade to the Shuttle system was not pursued. 


In 1990, the introduction of GPS had led the 
Department of Defense and the Federal Aviation 
Administration to plan the phase out of TACAN 
ground stations beginning in the year 2000 (Table 5). 
GPS promised better performance than TACAN and 
reduced operating costs. In response, then Shuttle 
Program Manager (and former astronaut) Robert 
Crippen initiated an effort to study the possibility of 
replacing the three TACAN units on each orbiter 
with three GPS receivers (Figure 3). 


Table 5 - Planned TACAN Phase-Out 
From The Federal Radionavigation Plan 


Planned Start of 

FRP Publication Date TACAN Phase-Out 


1990 

1990 

2000 

1992 

J une 1993 

2000 

1994 

May 1995 

2000 

1996 

July 1997 

2005 

1999 

December 1999 

2008 

2001 

March 2002 

2010 

2005 a 

? 

? 


a The 2005 Federal Radionavigation Plan was 
not available at the time of publication. A 
2003 Plan was not published. 



Figure 3 - Eventual phase-out of TACAN ground stations led NASA to 
upgrade a proven and highly successful Shuttle navigation system. 
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By 1996, the development of Embedded GPS/INS (or EGI) units employing strapdown inertial sensors 
[80] motivated the Shuttle program to look at an eventual replacement of the previously mentioned stand 
alone GPS (the TACAN replacement) and stable member, spinning mass gyro Kearfott High Accuracy 
Inertial Navigation Systems (HAINS) Inertial Measurement Units (IMUs) with EGIs. The use of 
strapdown IMUs employing ring laser gyro (RLG) technology was identified as a potential source of cost 
and schedule savings during orbiter pre-launch processing. 

Both the TACAN replacement and GPS/IMU replacement efforts were conducted in parallel. Studies 
were performed to determine the best integration architecture. Stand-alone GPS units and EGIs had to be 
integrated in a manner that did not compromise the integrity of an operational, certified navigation 
system. Once it was decided to tailor the GPS receiver requirements to TACAN replacement, studies 
were conducted to determine if there were other applications for GPS during Shuttle flights. 

Changes to the Shuttle General Purpose Computers (GPCs) to support both projects were identified. GPS 
and EGI hardware was selected; interface, software and hardware changes were identified and made. 
Both types of units were flown on a series of Shuttle missions for test and evaluation. Modifications were 
made to GPS and EGI software based on flight test results. 


Overview Of Space Shuttle Navigation System 

Navigation requirements for manned spacecraft are different than those for terrestrial aircraft, unmanned 
Earth orbiting satellites and interplanetary probes [81, 82]. The guidance, navigation and flight control 
system had to be designed to ensure safety of flight and mission success for ascent, orbit, rendezvous and 
gliding entry to a runway landing in the presence of system failures. For ascent and entry, a total of five 
computers, running in parallel, can control the vehicle. Four of the GPCs run what is known as the 
Primary Flight Software Sub-system (PASS) software. The fifth runs Backup Flight Software (BFS). 
Different contractors coded PASS and BFS software. The BFS contains a subset of the PASS functionality 
to enable the vehicle to finish nominal ascent, an abort or landing in the event of a generic PASS software 
failure. While on orbit, only PASS software provides guidance, navigation and flight control functions. 
Multiple navigation sensors, command paths and power buses within the avionics system ensure 
redundancy [83, 84]. Navigation sensors used in the "pre GPS era" are depicted in Table 6. 

For HAINS IMUs, TACANs, barometric altimeters and MLS units, redundant measurements are passed 
through Fault Detection, Identification and Reconfiguration (FDIR) algorithms [85]. Selection filters then 
process data from units deemed to be good. Selected measurements are then passed to the Shuttle 
navigation software. HAINS IMU data is used during all flight phases for attitude and sensed velocity 
determination. During entry, PASS and BFS Kalman filters process selected TACAN, IMU derived 
altitude and barometric altimeter measurements. Only the PASS Kalman filter processes selected MLS 
data. Selected radar altimeter data is provided for crew situational awareness, but is not incorporated 
into the navigation solution. 
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Table 6 - Legacy Space Shuttle navigation sensors. GPS supplements TACAN in the "single string" 
(one GPS) configuration. "Three string" GPS (three receivers) will replace the three TACAN units. 


Ascent 

Orbit and Rendezvous 

Entry 

• Three High Accuracy 
Inertial Navigation 

• Three HAINS IMUs 

• Two Hand Held 

Lasers (HHL) 

• Three HAINS IMUs 

System Inertial 
Measurement Units 

• Two Star Trackers 

• Two payload bay 

• Three TACANs 

(HAINS IMUs) 

• One Ku band 

television cameras 

• Four Barometric 

• Ground based C & S 

rendezvous radar 

with ranging ruler 
overlays 

Altimeters 

Band radar tracking 

• One Crew Optical 


• Three Ku Band 


Alignment Sight 

• Ground based C band 

Microwave Landing 


(COAS) 

radar tracking 

System (MLS) 

Receivers (on-board) 


• One Trajectory 
Control Sensor 

• Tracking And Data 

Relay Satellite 

plus ground equipment 


(TCS, a laser) 

System (TDRSS) 

• S Band Doppler 
tracking 

• Two Radar Altimeters 

• Ground based C & S 
Band radar tracking. 

• At least two TACAN 
ground stations. 


During rendezvous, a PASS Kalman filter processes on-board radar, star tracker and Crew Optical 
Alignment Sight (COAS) measurements. TCS and HHL data are processed in Kalman filters residing in a 
laptop computer for crew situational awareness. Television monitors with ranging ruler overlays 
provide range information to the crew during docking. The angle subtended by the target in the COAS is 
also a back-up source of range data. 


I ntegrating GPS I n A Loosely Coupled Architecture 

A loosely coupled architecture using cascaded filters is a common way of upgrading existing navigation 
systems with GPS. This method of integration has been used on platforms such as the F-16 [86], F-117 

[87] , Conventional Air Launched Cruise Missile [88] and B-2 [89]. 

A cascaded filter approach involves using the position output of the GPS receiver as a measurement for a 
Kalman filter in the host vehicle navigation system [86]. Position and velocity aiding data from the host 
vehicle INS are fed back to the GPS receiver to improve signal acquisition and tracking performance. 
However, the Kalman filter is derived under the assumption that measurements are not time correlated. 
This assumption is violated by processing the GPS position vector in the host vehicle Kalman filter. Time 
correlated measurements can lead to filter instability. This problem has been avoided in many 
applications by processing GPS position vectors at a low rate, such as no higher than every 15 seconds 

[ 88 ] . 
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One option considered was to process GPS position vectors as measurements in the PASS and BFS 
Kalman filters, as is done in many military applications. 

Another option studied was to convert GPS position into a TACAN measurement (known as "TACAN 
transparency"). This was an attempt to minimize or avoid changes to the PASS and BFS flight software 
and input/output. This would have resulted in a high rate cascaded filter implementation (TACAN 
measurements are processed every 3.84 seconds). A "transparent" approach would not have allowed 
INS aiding to be supplied to the receiver from the GPC. Crew displays required GPS receiver specific 
controls and quality assessments, and GPS data needed to be sent to Mission Control for the flight 
controllers. For on-orbit processing, a new Kalman filter would have to be created. On-orbit processing 
of "pseudo TACAN" measurements could only have been performed within the line-of-sight of the 
TACAN stations already in the flight software to support landing. 

Neither of the loosely coupled, cascaded filter options were acceptable to the Shuttle Program. 
Processing GPS as a TACAN measurement or filtering the GPS position vector could not have been 
evaluated in flight without actually incorporating the data into the navigation state. Both of these options 
would have required retuning the entry navigation Kalman filters in the PASS and BFS flight software. A 
new PASS flight software Kalman filter for the orbital phase of flight would have to be created. Any 
modifications to the existing filters for entry, or a new Kalman filter for orbit, would result in an extensive 
flight software development and certification effort. 


The Tightly Coupled Option 

In a tightly coupled integration, processing actual GPS measurements (pseudorange, delta range) from a 
GPS receiver in a host vehicle computer permits the navigation system designer to have more control 
over the quality of the navigation solution, rather than having to rely on a receiver vendor's proprietary 
software. Processing high rate, unfiltered GPS observables and inertial measurement unit data in a 
central Kalman filter permits higher accuracy navigation and less vulnerability to GPS outages and 
jamming. This architecture enables rapid estimation of GPS receiver clock errors and inertial 
measurement unit errors [86]. 

Processing of GPS pseudoranges in the PASS and BFS flight software was also considered, but not 
chosen. Like the cascaded filter options discussed previously, it would have required modifications to 
baseline entry navigation and a new Kalman filter for the on-orbit phase. Furthermore, there were 
security concerns with sending corrected pseudoranges outside the keyed GPS receiver to the Shuttle 
GPCs. Uncorrected pseudoranges could be processed in the GPCs, but the entry and new orbit Kalman 
filters would have to solve for the corruption due to Selective Availability. 
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State Replacement Chosen 


After considering eight integration options, the Shuttle Program directed that GPS be integrated "in 
parallel" with the existing baseline navigation on the orbiters. A GPS state (position and velocity) 
selected by the Shuttle flight software would overwrite the Shuttle flight software navigation state. "State 
replacement" in the Shuttle navigation software was chosen over treating GPS as a sensor and filtering 
the GPS measurements or state vector. This architecture treats the GPS receiver as a complete navigation 
system [1]. Any potential problems with cascaded Kalman filters would be avoided. State replacement 
could be implemented so that the same GPC flight software could be used for GPS processing during 
both orbit and entry. This was essentially the same integration architecture called for in a 1980 GPS 
upgrade proposal for the Shuttle. 

The Shuttle operates in a demanding flight environment with little margin for error. Shuttle software and 
hardware undergo an extensive test and validation process. Technical issues that arise before or during a 
flight can easily disrupt complex flight preparation schedules that span a period of years. The state 
replacement architecture lowered potential impact on the existing Shuttle navigation software, flight 
schedules and operations. GPS integration engineers also had to work within cost and schedule 
constraints and a desire to minimize hardware modifications to the vehicles. 

The integration architecture also allowed GPS receiver and Shuttle flight software GPS data collection to 
occur in the flight environment before certification, while still using the proven legacy navigation aids 
and Shuttle computer navigation algorithms [1]. This also permits operation of a "mixed fleet" of GPS 
and TACAN hardware configurations with the same version of PASS and BFS flight software. Due to the 
schedule of orbiter overhaul periods, not all orbiters would be equipped with GPS units at the same time. 
Supported TACAN/GPS configurations are (Figure 4): 

• Three TACANs for operational use and one GPS receiver (single string GPS) for data gathering (test 
flights) or operational use. 

• Three GPS units for operational use and no TACANs (three string GPS). 

• Three TACANs and no GPS unit onboard. 

It was believed that this approach would also make it easier to upgrade the Shuttle with more advanced 
receivers, whereas the Kalman filtering of GPS measurements or vectors in the Shuttle GPCs might 
require retuning the filters in the GPC. Furthermore, if a receiver upgrade occurred, it was believed that 
this approach would eliminate the need for detailed knowledge of the GPS receiver's software. 

The GPS receivers are provided with position, velocity and attitude aiding from the Shuttle flight 
software (PASS, or BFS in the event of a PASS software failure). One aiding state vector is propagated 
for all three receivers, using selected IMU data from candidates that have been screened by a FDIR 
algorithm. The single aiding state is periodically reset with the Shuttle navigation state. 
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FIGURE 4 - In the "single string" configuration, TACAN and GPS data may be processed 
concurrently. Microwave Landing System data takes priority over TACAN, GPS and 
barometric altimeter data. 

The PASS flight software subjects GPS state vectors to three Quality Assurance (QA) checks. The QA 
tests were designed so that retuning of the receiver Kalman filter, or changes to receiver residual edit tests 
would not be necessary for the Shuttle missionization. 


• A check of several receiver parameters, one of which is the Figure of Merit (FOM). 


• The current GPS state is compared with the receiver's previous state propagated to the current time. 


• Comparison of the receiver states with each other. 


If criteria for any of the QA tests are violated, that receiver's state is not a candidate for selection. State 
vectors from candidate GPS units are then processed in a selection filter. The BFS flight software uses a 


62 of 118 





simpler QA and selection scheme than PASS. There are crew controls that allow these QA tests to be 
bypassed, if necessary. 

Once the QA checks are complete and a GPS state has been selected, there are two crew commanded 
methods for incorporating the selected GPS state into navigation. The first involves automatic 
incorporation at a flight phase dependent rate, if the selected GPS state is within a tolerance of the current 
navigation state. The second method, called a "force," ignores the comparison test with the current 
navigation state and incorporates (forces) the selected GPS state into navigation. 

Six years of test flights (1996 to 2002) have proven that the state replacement architecture was the right 
choice. State replacement permitted the shuttle computers to conduct GPS QA tests and exercise the 
selection filter without using GPS as a primary source of navigation data. It also allowed the team to 
avoid modifying the legacy entry navigation Kalman filter, which has proven itself over 21 years (1981 to 
2002) of operation. The Shuttle Program was able to fly one set of Shuttle software, regardless of the 
TACAN and GPS hardware configuration, for as long as was needed, without committing to use GPS 
operationally. 

State replacement also enabled Mission Control to perform real-time comparisons of the selected GPS 
vector with the Shuttle navigation state, without incorporating GPS data into baseline navigation. This 
additional insight will help assess the health of the onboard and ground-based legacy navigation systems 
and resolve dilemmas between legacy sensors. Had the team chosen the cascaded filter architecture, it 
could have performed this assessment only in post flight simulations that processed selected position 
vectors in the onboard entry Kalman filter. 


Receiver Selection 


During the early to mid 1990s, use of Commercial/Modified-Off-The-Shelf hardware and software, and 

the "faster-better-cheaper" approach, were being stressed within NASA [90]. Use of an off-the-shelf 

receiver, and the success of GPS technology, was seen by some as the key to a quick, low cost Shuttle 

upgrade. For TACAN replacement, the Shuttle Program desired an off-the-shelf, in production military 

unit designed for aircraft to take advantage of the existing production line and logistics base. The Shuttle 

Program also desired to be an authorized user of GPS, to take advantage of the jamming and spoofing 

resistance provided by military GPS Originally 
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entered production in 1994 [91]. All-in-view military aviation receivers of this type did not become 
available until the late 1990s (Figure 5). The receiver tracking loops were digital, rather than analogue, 
and could be modified to obtain measurements and download data at orbital velocities through software 
changes, rather than through changes to discrete electronic components, as was required with earlier 
receivers. The MAGR had several desirable capabilities, including authorized operation and the ability to 
accept inertial aiding data from an Inertial Navigation System (INS). A change to the receiver power 
supply and input/output electronics card was required to make the receiver compatible with the orbiter 
power system and data bus. Radiation testing of the receiver at the Indiana University Cyclotron Facility 
indicated that no hardware changes were required to meet radiation exposure requirements. 

Existing space rated GPS receivers were not suitable for the Shuttle (i.e. didn't accept inertial aiding from 
an INS, too big and heavy for the Shuttle, not capable of authorized operation). 


GPS Antennas 

Each GPS receiver uses two antennas (Figures 6 and 7), which are mounted under the Shuttle thermal 
protection system, which does not significantly attenuate the GPS signal. The antennas provide direct 
visibility of satellites in any attitude while on-orbit or during entry. The signal from each antenna is 
amplified by a pre-amplifier, then is passed to a signal combiner to provide one input to the receiver. 
Antenna switching is not conducted. 

The single string MAGR/S flown during the test phase has two antennas, one on the top and one on the 
bottom of the crew compartment (GPS 2 in Figure 6). Antennas and cables used for the single-string 
configuration were actually installed in the Shuttles Discovery, Atlantis, and Endeavour when they were 
built in the 1980s. For the three-string configuration (Figure 6), antennas for GPS units 1 and 3 occupy the 
former positions of TACAN antennas (Figure 7). 


I nitial Flight Tests And Receiver Missionization 

The first flight of a GPS receiver on the Shuttle was on mission STS-51 in September of 1993 [92]. A 
Trimble TANS Quadrex was flown. This experiment was not a part of the TACAN replacement project. 
The Quadrex was mounted in an overhead window on the flight deck. Signal attenuation from the glass 
and limited field of view severely impacted receiver performance. 

The initial flight test program supporting TACAN replacement involved the 5 channel, Collins 3M 
receiver. The 3M was a pre-production version of the Collins MAGR. This series of flight tests was 
intended to prove if a GPS receiver designed for terrestrial aircraft use could function on the Space 
Shuttle with a minimum number of software changes. 
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Figure 6 - Three string GPS antenna configuration of Endeavour, circa 2005. 



Figure 7 - Three string TACAN and single string GPS antenna configuration 
of Atlantis and Discovery, circa 2005. 

INS aiding was supplied to the 3M by the BFS GPC during ascent and entry, while on-orbit the receiver 
was unaided and operated by a laptop computer. Receiver state vectors and other 3M data were 
recorded on the laptop. The 3M was not keyed. Since the purpose of the 3M flight tests was purely data 
gathering, no navigation data was sent from the 3M receiver to the BFS GPC. The Collins 3M unit flew 
seven times (December, 1993 to May, 1996) on Endeavor (flights 61, 59, 68, 67, 69, 72 and 77) (Table 1, page 
21, and Table 7, page 66). Modifications were made to the 3M software between flights based on flight 
test results. 

Flardware and software missionization of the Collins production MAGR for TACAN replacement began 
in 1995. The version of the MAGR flown on the Shuttle is known as the MAGR/S (MAGR/Shuttle). 
Collins based MAGR/S software on military MAGR Link 008, with Link 009 and 010 modifications also 
included. Lessons learned from the 3M flights were also incorporated into the MAGR/S software. 
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"Single String" Tacan Replacement Flight Tests 


A single MAGR/S unit (the "single string" configuration, one MAGR/S and three TACAN units) was 
flown on each orbiter during the flight test and certification program for data collection (Table 7, Figure 

7)- 


Table 7 - Shuttle GPS Test Flights For TACAN Replacement 


GPS 

Receiver 

Year 

Orbiter 

Shuttle Missions 

3M 

1993 

Endeavour 

61 


1994 

Endeavour 

59, 68 


1995 

Endeavour 

67, 69 


1996 

Endeavour 

72, 77 

MAGR/S 

1996 

Endeavour 

79 


1997 

Endeavour 

81, 82, 84, 85 


1998 

Endeavour 

89, 88 



Discovery 

91, 95 


1999 

Discovery 

96, 103 


2000 

Atlantis 

101,106 



Discovery 

92 



Endeavour 

99, 97 


2001 

Atlantis 

98, 104 



Discovery 

102, 105 



Endeavour 

100,108 


2002 

Atlantis 

110,112 



Columbia 

109 



Endeavour 

111, 113 


2003 

Columbia 

107 


2005 

Discovery 

114 


On many flights, a laptop computer was used to record instrumentation port data, in addition to receiver 
data normally transmitted to Mission Control during a mission. This data greatly enhanced vendor 
efforts to track down and resolve complex software issues in the GPS receiver. After every flight, the GPS 
team examined fault logs. 


MAGR/S data was available in "real time" to Mission Control personnel during ascent and entry. More 
flights followed as each orbiter in the fleet was equipped with a single MAGR/S receiver. STS-91 in June 
of 1998 was the first flight during which GPS data was available "in real time" to Mission Control 
personnel during the orbital phase of flight. By the flight of Columbia on STS-109 in 2002, all four orbiters 
were flying with one MAGR/S receiver each, in the single string configuration. 


From STS-79 (September 1996) to STS-107 (January/February 2003), the Shuttle Program has accumulated 
-7,000 hours of MAGR nominal performance operating time from launch through landing. In 
comparison, -100 hours of TACAN nominal performance operating time have been accumulated from 
Mach 10 through landing from STS-1 (April 1981) through STS-113 (November/December 2002). 
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GPS Tests 


Detailed Test Objectives (DTOs) were carried out during the single string flights. These tests involved 
astronaut execution of MAGR/S procedures. Selected MAGR/S state vectors were incorporated into the 
PASS and BFS flight software on several occasions while on orbit. On STS-103 (December 1999, before 
the deactivation of Selective Availability), the MAGR/S was intentionally unkeyed prior to entry. The 
Shuttle is certified to land with the MAGR/S unkeyed. Another DTO involved a late power-on of the 
MAGR/S just prior to entry on STS-92 (October 2000). This tested the ability of the MAGR/S to collect 
ephemerides, download the daily key and establish four satellite navigation during entry. 

Pre-Launch Ephemeris Collection 

The launch pad multi-path environment, obscuration of the lower antenna by the external tank, and non- 
optimal pointing of the upper antenna (boresight at the horizon) made pre-launch ephemeris collection 
difficult. This became a serious concern, as GPS may be required to support an emergency landing soon 
after launch. Simulation studies indicated that four hours were needed to collect GPS satellite 
ephemerides that would be needed for an emergency landing in Europe or North Africa. As GPS is 
powered on about five hours prior to launch, no changes were needed in the pre-launch time line. 

The team did not consider loading the receiver with ephemerides before liftoff using a data port and 
laptop computer. It would have been difficult to fit such a procedure into an already-crowded pre-launch 
timeline, and would have required orbiter hardware modifications to permit easy access to the GPS 
receiver from the crew compartment and an ephemeris verification procedure. 

Ascent Performance Results 

For most of ascent, the Shuttle is in a heads down configuration. The GPS antenna on top of the crew 
compartment is facing the Earth, while the antenna below the crew compartment is facing the External 
Tank. In spite of the poor antenna visibility, enough GPS signals wrap around the External Tank and 
orbiter to permit the MAGR/S to track three to four satellites most of the time. However, the Geometric 
Dilution Of Precision (GDOP) is high, which can result in large state errors. On most flights, a roll to a 
heads up attitude is performed at about 6 minutes into the flight. This provides excellent GPS satellite 
visibility to the antenna on top of the crew compartment. Receiver tracking and performance during this 
phase of ascent is usually exceptional. 

On-Orbit Performance Results 

While on-orbit, noisy GPS velocity incidents (Figure 8) occurred that are consistent with the spatial (near 
the geomagnetic equator) and temporal (early evening to early morning) characteristics of ionospheric 
scintillation (Figure 9). Analysis has indicated that the velocity anomaly is induced by ionospheric 
scintillation of the phase of the GPS signals, which manifests in the delta-range measurements. Velocity 
noise as high as 11 feet per second has been observed and noise periods have lasted up to 20 minutes. 
Velocity noise was judged not to be a constraint for operational use of GPS by the Shuttle [93, 94]. 
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STS-88 GPS Velocity Noise (December 1998) 
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Figure 8 - Comparison of GPS velocity with Shuttle on-board navigation velocity, illustrating ionospheric scintillation 
induced velocity noise periods on three consecutive orbits. Bias is due to error in Shuttle on-board navigation state. 


Qn-orbit, GPS vectors did not permit orbit determination as accurate as that obtained with Mission 
Control processing of TDRSS and ground radar tracking data. This was expected, as the MAGR/S unit 
was not modified to support high accuracy orbit determination. Multi-path and upper antenna 
obscuration that occurs while the Shuttle is docked to the ISS degrades receiver performance, but it does 
not pose an operational impact. MAGR/S radiation testing conducted in 1997 indicated that no hardware 
modifications were required. To date, no on-orbit anomalies have occurred that could be traced to 
radiation effects. 

Entry Performance Results 

Receiver performance during the "blackout" or "plasma" region of entry was a concern (Figure 10). 
However, flights since 1993 have indicated that an inertially aided, five-channel receiver can track from 
one to five satellites during plasma, and a true "blackout" of GPS signals rarely occurs. Frequent loss of 
lock and reacquisition occur, along with less than optimal GPS satellite geometry. GPS state vector errors 
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FIGURE 9 - Geographic distribution of ionospheric scintillation induced delta range noise for STS-99 
(February 2000), during the solar maximum. The geomagnetic equator and dip angle contours for ± 15 
and ± 45 degrees are indicated. 

during this period were not excessive. Lower antenna tracking can be impacted by plasma as high as 
320,000 feet, and the lower antenna may not resume continuous tracking until about 185,000 feet. The 
most severe plasma period impacts the upper antenna, and typically begins around 285,000, when the 
first roll maneuver occurs. Continuous upper antenna tracking of satellites typically resumes between 
220,000 feet and 200,000 feet. 

The impacts of the plasma region on the MAGR/S are extended periods of less than four satellite tracking, 
failed reacquisition attempts, incomplete data collection (i.e. ephemerides) and loss of delta range 
measurements. Less than optimum number of measurements and poor satellite geometry could result in 
an increasingly inaccurate GPS state vector. However, navigation errors during the plasma region have 
so far not been excessive. The orbiter can fly through this region without an update from GPS. 

Roll maneuvers during entry outside the plasma region had little or no impact on receiver performance. 

Figure 11 depicts legacy entry navigation and selected GPS average +3 sigma position differences using a 
post-flight Best Estimate of Trajectory (BET) as the reference. The BET process blends Shuttle on-board 
data (IMU, MLS) with ground radar tracking, but does not include GPS data (GPS may be more accurate 
than the BET). Legacy navigation data is from 49 recent Shuttle flights, while the GPS data used was from 
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Figure 10 - Receiver data from an altitude of 400,000 feet through landing. Figure of Merit (FOM) is the 
receiver's estimate of it's position accuracy. The Shuttle computers will not use GPS data if the FOM is 6 or 
greater. Geometric Dilution of Precision (GDOP) indicates how well the satellite geometry will enable the 
receiver to resolve navigation errors. The Less Than Four Satellite Tracking bit is "1" if less than four 
satellites are tracked. The plasma region for this flight was roughly from 260,000 feet to 210,000 feet. On 
most flights, FOM and GDOP typically have low values from the end of the plasma region through landing. 


12 single-string GPS test flights. The legacy navigation system, even at the 3-sigma level, is well within 
guidance constraints for maximum allowable navigation error. GPS is considerably more accurate than 
the legacy entry navigation system. The 3-sigma keyed receiver accuracy specifications for position are 31 
meters horizontal and 36 meters vertical. The 3-sigma velocity specification is 0.1 meters/second in both 
the horizontal and vertical directions. 
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Figure 11 - Average ± 3-sigma position differences for entry legacy navigation and selected GPS using a post-flight 
Best Estimate of Trajectory (BET) as the reference. The BET includes ground radar and on-board (IMU and MLS) 
data, but does not include GPS data. Ground radar tracking begins between 160,000 and 150,000 feet, while MLS 
data processing begins around 17,000 feet. The gradual decrease in the BET versus GPS differences (particularly 
noticeable in down-track) is due to deceleration sensed by the IMUs, which improves BET accuracy. The plasma 
region (-270 to -220 kiio-feet) has little impact on receiver accuracy. Guidance constraints (heavy lines) represent 
the maximum navigation error under which guidance can still fly the Shuttle to a runway. 


Shuttle Software Changes 

Flight data from the MAGR/S as well as the GPC QA checks are examined both during and after 
missions. Flight tests and simulation results have driven changes to the MAGR/S software and PASS and 
BFS flight software that processes MAGR/S data. 

Flight experience also drove a change to the position and velocity vector-aiding scheme used by the PASS 
flight software. The original design involved propagation of a separate aiding state for each receiver. 
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with each propagator having an independent source of IMU data (i.e. an IMU is assigned to each 
receiver). Instead, one aiding state vector is propagated for all three receivers, using selected IMU data 
from candidates that have been screened by a FDIR algorithm. Instead of periodically resetting the 
aiding states with each receiver's own GPS state, the single aiding state is periodically reset with the 
Shuttle navigation state. The original design did not perform a sanity check on the GPS states used to 
reset the aiding states in the PASS flight software. Resetting the single aiding state with the Shuttle 
navigation state takes advantage of protection provided by the GPS QA checks, the GPS state selection 
process and the comparison of the selected GPS state with the current navigation state before GPS 
incorporation. The new aiding scheme also permits the ground to have more insight into and control 
over the position and velocity aiding states sent to the receivers. 

GPS Availability 

The five channel MAGR/S uses four channels to obtain navigation measurements, and a fifth for 
ephemeris collection and satellite acquisition. New satellites needed to maintain track of an optimal set 
of four are acquired sequentially. Under difficult tracking conditions (multi-path, antenna obscuration, 
satellite line-of-sight off of the antenna gain pattern), multiple satellite switches could fail or be delayed, 
resulting in less than optimal satellite geometry or less than four satellite tracking for extended periods of 
time. The receiver's estimate of its position accuracy could exceed a Shuttle computer GPS quality 
assurance test limit, which would prevent the Shuttle computers from using position and velocity data 
from that receiver. A lack of GPS updates during entry could make it difficult for the Shuttle to reach the 
runway [84]. 

The Shuttle GPS team conducted an extensive simulation campaign using a GPS receiver, two GPS signal 
generators (one for each antenna, upper and lower), and Shuttle entry trajectories, to determine whether 
the GPS receiver could experience a loss-of-service for longer than 2.3 minutes between an altitude of 
140,000 feet and touchdown on the runway. A failure of any of the tests to meet the loss-of-service limit 
would have necessitated changes to the receiver to lower the probability of loss of service. Simulation 
results indicated that such changes were not required. 


Status of Shuttle TACAN Replacement 

Delay in Certification 

The original flight of three string GPS (no TACANs) was planned for 1999. However, due to the number 
of GPS software issues encountered during flight and ground testing, and a slip in the TACAN 
decommissioning date (Figure 5, page 63, and Table 5, page 57), certification of Shuttle GPS for 
operational use was delayed by three years, from 1999 to 2002. Additional receiver software versions, 
laboratory test campaigns and Shuttle test flights were scheduled. The project was reorganized to 
enhance communication between project participants, and to improve identification, documentation and 
resolution of issues. The NASA independent verification and validation contractor audited the MAGR/S 
software, which had been developed at government expense. By March of 2002, all four orbiters had 
flown with one MAGR/S receiver installed for data collection, and for use in contingencies defined in 
Shuttle Program flight rules. 
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Certification Status 


The MAGR/S and associated Shuttle computer software was certified for TACAN replacement in August 
of 2002, over three years after the original target date. Uses for the single MAGR/S receiver configuration 
(Figures 4 and 6), in conjunction with TACAN, on each orbiter were identified, and the receiver and 
associated Shuttle computer software was certified for these applications in December of 2002. 

TACAN Replacement on Endeavour 

On October 23, 2003, the Shuttle Program approved the removal of the three TACAN units from 
Endeavour, and the installation of two additional MAGR/S receivers, bringing Endeavour to the three- 
string GPS configuration (Figure 4, page 62, and Figure 6, page 65). Once Shuttle flights resume, a ramp- 
up of increasing single string GPS use on Discovery and Atlantis in conjunction with TACAN will be 
performed (Figure 7). These flights will lead to Endeavour flying the first all GPS, no TACAN flight, 
which is expected to occur in 2006. 

GPS On Discovery and Atlantis 

Both Discovery and Atlantis are equipped with one GPS receiver and three TACAN units (Figure 4, page 
62, and Figure 7, page 65). During entry, GPS data will be incorporated into the primary and backup 
flight computers simultaneously with TACAN data. Since the TACAN phase-out initiation date has 
slipped to 2010 (2001 Federal Radionavigation Plan), TACAN availability is not considered to be a 
problem. Contingent upon Shuttle Program direction, one or both of the orbiters may have their 
TACANs removed and two MAGR/S receivers added as they cycle through the periodic Orbiter Major 
Modification activity. 


Mission Control And On-Board, Operational Use Of GPS By Flight Phase 

The following sections give an overview of the current Shuttle navigation methodology. How GPS states 
will be used by the orbiter navigation system and Mission Control after MAGR/S certification is covered. 

Pre GPS Ground Tracking 

Initially, the Shuttle Program required continuous tracking from 2 radars during ascent and entry, so that 
Mission Control could determine the Shuttle state independently of the on-board navigation system. As 
confidence was established in the on-board system, the ascent/entry ground tracking requirement was 
changed from mandatory to highly desirable. 

Prior to launch, if there are certain failures on the vehicle, radar tracking to support navigation is 
required to meet Launch Constraint Criteria. C Band (range and angles) and S Band (range, Doppler, 
angles) radar data is processed in a Mission Control based Kalman filter. The filter can process data from 
one S Band and two C Band radars. 
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If the Shuttle is to rendezvous with a spacecraft already in orbit (a "ground up rendezvous," such as with 
the International Space Station or Hubble Space Telescope), Mission Control checks the cross track 
velocity error after Main Engine Cut Off. A state vector update may be required prior to the OMS-2 
maneuver for cross-track velocity error greater than 6 feet/second. The uplink would be based on ascent 
ground tracking data processing. 

Initially, S Band communication sites provided tracking (range, Doppler, angles) during the orbital phase 
of flight, when the orbiter was visible. As TDRSS satellites were launched, ground S Band use for orbit 
was reduced. When available, TDRSS provides near global communications coverage, but only Doppler 
measurements due to the type of S Band transponder on the orbiter. 

Qn-orbit, both S Band TDRSS Doppler measurements; and C Band radar data (range and angles from a 
number of tracking stations) are processed to estimate the orbiter's state vector. The on-board navigation 
state is usually allowed to grow in down-track position error before a new state, based on radar and 
TDRSS tracking, is uplinked. For landing, the maximum allowable downtrack position error at Entry 
Interface (400,000 feet) is 20 nautical miles. 

TDRSS S Band Doppler tracking provides a good estimate of the orbital semi-major axis (which reflects 
both position and velocity). C Band tracking resolves planar errors. Radar geometry plays a large role in 
determining the accuracy of ground-based navigation. On-orbit, a weighted least squares algorithm is 
used by Mission Control for orbit determination. 

Ground-up rendezvous flights require radar tracking of the target spacecraft. Radar tracking begins from 
18 to 24 hours prior to Shuttle launch. Ground tracking of the target spacecraft continues through 
docking (ISS) or grapple (Hubble Space Telescope). If the orbiter deploys a scientific payload that is to be 
retrieved later in the mission, ground tracking of the deployed spacecraft will be performed to facilitate 
the rendezvous and grapple. 

For entry and landing. Mission Control processes radar data in the previously mentioned Kalman filter 
for independent assessment of onboard navigation systems. Since Shuttle landings are planned for the 
Kennedy Space Center (KSC), and radars are located there to support the Eastern Test Range, C Band and 
S Band radar tracking is usually available. C Band tracking is also usually available for landings at 
Edwards Air Force Base, since NASA has radars at the Dryden facility. However, range scheduling can 
prevent entry tracking. If there are certain failures in the on-board or ground navigation systems, radar 
tracking during entry becomes mandatory. 

During entry, radar normally becomes available in time for Mission Control to assess the TACAN units 
and navigation state health prior to TACAN processing in the GPCs. Mission Control can also perform 
an emergency state uplink to the orbiter if navigation errors are excessive. 
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Post GPS Ground Tracking 


After GPS certification, the Shuttle Program still considers radar tracking during ascent to be desirable, 
but not required, unless there are navigation equipment failures on the vehicle. 

Radar and TDRSS tracking will still be used during the orbital phase to support maneuver planning in 
Mission Control. The MAGR/S Kalman filter has not been tuned for orbital dynamics, since emphasis 
was on a TACAN replacement and a Commercial-Off-The-Shelf approach that minimized MAGR/S 
modifications. 

Shuttle Spacecraft Position Optimal Tracking (SPOT) Filter 

The MAGR Kalman filter and navigation algorithms were designed so that the unit could be integrated 
into a wide variety of atmospheric flight platforms without having to substantially modify the navigation 
algorithms to support specific integrations [95]. Filter tuning assumes a worst case inertial measurement 
unit and receiver clock. The downside to this approach is that the receiver is not optimized for space 
navigation. It effectively provides a blended deterministic solution without accurate gravity or drag 
modeling needed for accurate orbit determination. The performance of these algorithms is sufficient to 
support TACAN replacement and Shuttle deorbit burns. 

However, MAGR/S velocity errors, and the resulting semi-major axis errors, render the receiver incapable 
of performing the high accuracy orbit determination currently performed with ground radar and TDRSS 
tracking to support post-insertion orbit assessment, orbit maneuver planning, debris avoidance analysis, 
and rendezvous. Poor orbital navigation performance of GPS receivers originally designed for terrestrial 
use and the importance of semi-major axis accuracy is covered by Carpenter and Schiesser [23]. 
Although the MAGR/S was modified by the Shuttle Program to improve velocity accuracy on-orbit, the 
improvement was insufficient to facilitate precision orbit determination. 

To take advantage of the near continuous availability of GPS state vectors from the Shuttle, a Mission 
Control based filter, called Shuttle SPOT, was developed (Figure 12). Shuttle SPOT processes MAGR/S 
state vector data to provide an improved estimate of the orbit. MAGR/S data from Shuttle missions 88, 
96, 99, 106 and 108 was used to tune and certify the filter. Although a few technical issues arose, these 
were resolved and the development and certification of SPOT for the Shuttle was relatively 
straightforward. The filter will be certified for use after a flight following and evaluation phase over 
several Shuttle missions. 

Near continuous availability of ground filtered GPS state vectors, in conjunction with radar and TDRSS 
tracking, will allow more responsive mission planning. Burns will be confirmed more rapidly than with 
radar and TDRSS data alone. If the orbiter is subjected to perturbations that are not modeled by Mission 
Control, it can take 2 or 3 revolutions before enough ground and TDRSS tracking data is available to 
quantify the impact on the orbiter state. SPOT will permit much more rapid perturbation determination. 
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Figure 12 - GPS vectors filtered by Mission Control will be used to 
support shuttle maneuver planning and debris avoidance. 


Ground radar tracking will be used on no-TACAN flights as a backup to GPS. TDRSS is also used for 
telemetry and communications, thus the Doppler measurements will always be available for processing. 
However, radar and TDRSS will still be designated as backups to GPS, and Mission Control Center 
personnel will maintain proficiency in C Band and S Band measurement processing. 

Pre-GPS Ascent And Post I nsertion 

Navigation aids (TACANs, barometric altimeters, MLSs, radar altimeters) that would be used for an 
emergency landing due to an ascent abort are powered on and self tests are run prior to the day of 
launch. The three HAINS IMUs are calibrated and aligned before liftoff. Only HAINS IMU data 
(accumulated sensed velocity, gimbal angles) are processed by PASS and BFS navigation during powered 
flight [96]. No sensor measurements are processed by an on-board Kalman filter. 

Ascent And Post I nsertion I n The GPS Era 

There is no change to the Shuttle baseline navigation (use of HAINS IMU data) for powered flight. The 
MAGR/S units will be turned on approximately 5 hours prior to liftoff. This permits receivers to collect 
ephemerides of satellites that will be over the Trans Atlantic Landing (TAL) sites at launch. GPS states 
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are not used by the Shuttle navigation software during powered flight, but receiver aiding data is 
supplied to the MAGR/S units by the GPCs. 

After the GPS SPOT Filter is certified, it could be used as a source of post Main Engine Cut Off state 
vector uplinks. GPS vectors from the on-board MAGR/S units would not be incorporated directly into 
navigation. 

GPS Metric Tracking For Range Safety 

The Shuttle Program examined the use of GPS for Space Shuttle range safety metric tracking during 
launch, to replace radars at the launch site. Radar replacement would have required the addition of GPS 
receivers, cables and antennas to the Solid Rocket Boosters and External Tank. The orbiter GPS 
receiver(s) could not be used as a source of range safety data, as they receive aiding data from the orbiter 
avionics system and therefore are not an independent source of state vectors. Even with a switch to GPS 
metric tracking, C band radars would still be needed to support Space Shuttle operations. Radar tracking 
is highly desirable to support launch and emergency landings at the launch site soon after launch, to 
backup the Shuttle's onboard navigation system. Radar tracking is mandatory for landing if there are 
navigation unit failures on the vehicle, and radar is needed to support orbit determination for 
rendezvous flights. In October of 2001, the Shuttle Program decided against a transition to GPS metric 
tracking for Space Shuttle range safety, as GPS metric tracking integration costs exceeded ownership and 
maintenance costs of launch site radars. 

Pre-GPS Orbit Coast Navigation 

During the orbit phase, the on-board navigation state is monitored and maintained by Mission Control 
via state vector uplinks. A vent force may also be uplinked by Mission Control for use by the GPCs. This 
takes into account non-propulsive forces acting on the orbiter that cannot be detected by the HAINS 
IMUs, and reduces error growth in the on-board state. Vent values are based on flight history for specific 
orbiter attitudes. The orbiter state (and for a rendezvous, the target spacecraft state) determined from C 
Band and S Band tracking are used by Mission Control for maneuver planning. 

Alignment of the HAINS IMUs is periodically performed using star sightings [97]. Two star trackers 
with near orthogonal lines of sight are located on the nose of the orbiters. Data from star sightings can 
also be used by Mission Control to determine IMU gyro biases. The ground determined biases are then 
uplinked for use in the Shuttle PASS flight software. If the orbiter cannot maneuver to a star sighting 
attitude due to excessive IMU misalignment, a rough alignment can be executed by a crew member 
sighting on a star using the Heads Up Display (HUD) or the CO AS. This would be followed by a precise 
star alignment using the star trackers. 

Orbit Coast Navigation I n The GPS Era 

Current plans call for two of the three MAGR/S receivers to be powered off for most of the orbit period. 
MAGR/S state vectors will periodically be taken into the PASS flight software to maintain the on-board 


77 of 118 



navigation state accuracy at an acceptable level. Ground and TDRSS tracking will remain the primary 
source of state vectors for maneuver planning in Mission Control, until the GPS SPOT Filter is certified. 

There is no provision for GPS attitude determination in the MAGR/S. Star sightings will still be used for 
precise HAINS IMU alignment. 

Pre GPS Rendezvous 

Successful rendezvous requires an accurate relative state for on-board burn targeting and target track 
attitude maintenance. Relative velocity errors, in particular, are critical. However, ground tracking of the 
orbiter and the target spacecraft is not accurate enough to guarantee a safe rendezvous within the 
orbiter's tight propellant budget. An on-board navigation system that provides an accurate relative state 
is required. 

Shuttle rendezvous is divided into two phases, ground targeted and on-board targeted. For the ground- 
targeted phase, the orbiter navigation state is determined by ground based radar and TDRSS tracking as 
described previously. Burns to be executed by the orbiter are computed by Mission Control (hence the 
term "ground targeted") and uplinked to the vehicle for execution by the crew. The last ground targeted 
bum is performed on the day of rendezvous, 40 nautical miles behind the target, at about orbital noon. 
During the on-board targeted phase (Figure 13), relative sensor measurements are processed in a Kalman 
filter in the PASS flight software [98]. The PASS software maintains an estimate of the target spacecraft 
state (initially provided by Mission Control) and the filtered orbiter state in an inertial frame. These 
states are used to compute bum solutions using an onboard Lambert targeting algorithm [99]. 

The star trackers used for IMU alignments are also used to process angular measurements of the 
orbiter/target relative state. This permits resolution of navigation errors normal to the star tracker line of 
sight. The star tracker pass begins shortly after the last ground-targeted maneuver, and will resolve most 
altitude and out-of-plane position errors. Due to change in relative geometry, some down-track position 
error will be resolved at the end of the star tracker pass. The end of the pass roughly coincides with 
orbital sunset, and is followed by the first on-board targeted maneuver. 

Incorporation of Ku Band radar measurements begins at a range of 135,000 feet. Range, range rate and 
angular data are obtained from this point until a range of about 100 feet. Five more on-board targeted 
bums are executed to control the orbiter's approach to the target spacecraft. 

At a range of approximately 8 nautical miles, there is another opportunity for a daylight star tracker pass, 
in the event of a radar failure. Due to the size and brightness of the ISS, optical tracking during orbital 
daylight may not be possible for this pass. A tracking light on the ISS facilitates processing of star tracker 
data at night. The ISS maneuvers to a night star tracker attitude at a predetermined time during the 
rendezvous. Such a failure occurred on STS-92 (October 2000), forcing execution of an "angles only" 
rendezvous. The rendezvous and docking was successful, but with slightly higher propellant 
consumption. 


78 of 118 




1. NC, last ground 
targeted burn. 

2. Start star tracker 

3. End star tracker 

4. NCC, first on-board 
targeted burn. 

5. Start Radar 

6. Ti Burn 

7. Start star tracker 
(for radar fail) 

8. MC-1 Burn 

9. Sunset 

10. End star tracker 
for radar fail. 

11. MC-2 Burn 

12. Sunrise 

13. MC-3 Burn 

14. MC-4 Burn 

15. Manual piloting 
phase using radar, 
phase using radar, 
TCS S< HHL. 


Axes are in kilo-feet 
NCC - Corrective Combination 
Ti - Transition initiation 
MC - Midcourse Correction 


Figure 13 - Day of rendezvous profile with burns and navigation activities indicated. Relative 
coordinate frame centered on the target spacecraft. "V Bar" is in the direction of target motion, 
"R Bar" is in the direction of the center of the Earth. 


If both the radar and star trackers are failed, the COAS may be used manually by the crew to obtain 
relative angular measurements. COAS measurements have never been taken in flight due to a sensor 
failure. However, after the undocking from Mir on STS-71 ( Atlantis , June-July 1995), COAS data was 
processed as a test. 

After the final on-board targeted bum, at a range of about 2,000 feet, the manual piloting phase begins. 
Radar data continues to be incorporated into the orbiter navigation state during the manual phase, but 
the primary source of relative navigation data for piloting comes from the Trajectory Control Sensor 
(TCS). TCS is a laser system mounted in the payload bay that provides relative range, range rate and 
angular information. TCS requires retro-reflectors on the target vehicle. Two Hand Held Laser (HHL) 
range finders are also carried. Both TCS and HHL can lock on to the target as far out as 5,000 feet. 

A Kalman filter is used in the primary and backup laptop computers to process TCS measurements. 
HHL measurements are processed in the primary laptop, in a different Kalman filter than TCS. 
Television cameras in the payload bay, with ranging ruler overlays on the monitors, are used by the crew 
as an additional range information source from 15 feet to docking. Ku Band radar, TCS and HHL are 
also used during undocking and fly-around, when the orbiter leaves the ISS. 
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Shuttle Rendezvous I n The GPS Era 


Even if both spacecraft have GPS units, simple subtraction of state vectors does not provide an accurate 
enough relative state for use in bum computation. Use of such data could easily result in an unsafe 
trajectory and an undesirable level of propellant consumption. 

Development of the on-board rendezvous navigation system for Apollo [99, 100] (on which the Shuttle 
system was based) proved that rendezvous could be accomplished with high inertial state errors on both 
vehicles, but low relative state errors [101]. High accuracy inertial states on both spacecraft are not 
enough to permit accurate rendezvous navigation. 

If GPS relative navigation were to be used for spacecraft rendezvous, identical GPS receivers on the target 
and chaser vehicles would be required. Processing of common satellite measurements from both vehicles 
in one Kalman filter permits the cancellation of common errors and biases (such as ionospheric error and 
Selective Availability) [102], This in turn drives the need for a radio data link between the vehicles. 

The Space Shuttle Program had to preserve the capability to rendezvous with spacecraft that are not 
equipped with GPS units, such as the Hubble Space Telescope. The current suite of on-board, relative 
navigation sensors (radar, star trackers, lasers) provide relative states that are just as good as or better 
than the level of accuracy possible with relative GPS. 

Furthermore, the International Space Station requirements for GPS were limited to coarse orbit 
determination to support pointing of antennas to the TDRSS satellites. Obscuration of GPS signals by ISS 
structure and multi-path would pose a significant problem for relative GPS in close proximity to the 
station. The Shuttle Program currently has no plans to use relative GPS for rendezvous. 

Pre-GPS Deorbit 

Currently, a state vector uplink is performed prior to the deorbit burn to both the PASS and BFS flight 
software. This uplink is based on Mission Control processing of ground radar C Band and TDRSS S Band 
data. 

Deorbit I n The GPS Era 

The current operations concept calls for the three MAGR/S units to be operating 6 hours prior to the 
deorbit burn. Selected MAGR/S data will be incorporated into the Shuttle navigation software prior to 
the burn, replacing the uplink from Mission Control. As with ascent and orbit insertion, MAGR/S data 
will not be incorporated into navigation during powered flight. 

Pre-GPS Entry Navigation 

For most of entry, three independent navigation states are maintained in the PASS [103]. Each uses 
accumulated, sensed velocity data from a different IMU to protect against IMU failures. A selection filter 
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selects one navigation state (position and velocity) for use in the Kalman filter. It is also passed on to 
guidance, flight control and crew display functions. 

The first navigation filter measurement to be processed is called "drag altitude." Measurement 
incorporation begins when the IMU sensed deceleration is greater than 11 ft/sec 2 (Figure 14). 
Accumulated sensed delta velocity data from the IMUs are used to estimate atmospheric density. A math 
model of the atmosphere then provides a rough estimate of altitude. Drag altitude measurements are 
rather inaccurate, but are intended to bound error growth in the event of other navigation system 
failures. 



Figure 14 - Availability of navigation sensors and systems during entry. BFS does not process 
MLS, but processes TACAN and Baro all the way to landing. Radar altimeter data is for crew 
situational awareness only. Ground tracking (radar) data is used by Mission Control for 
independent assessment of onboard navigation systems. 

Kalman filter processing of selected TACAN range and bearing measurements begins at a range no 
greater than 400 nautical miles from the runway and an altitude of roughly 140,000 feet (for a nominal 
entry and landing). TACAN bearing is not processed when the elevation angle of the slant range is 35 
degrees or greater (cone of confusion). 

Significant navigation errors during entry can exceed the ability of the guidance and flight control system 
to fly the orbiter to the landing site. A set of limits, called guidance constraints, defines the maximum 
allowable state error. In the event of a navigation error that exceeds the constraints, a correction to the 
state vector can be uplinked directly to the PASS and BFS flight software or voiced to the crew for manual 
entry. The "delta state update," which is based on radar tracking data, has never been executed in flight. 
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Barometric altimeter measurements are processed to control navigation errors in the vertical channel. 
Two barometric altimeter probes are deployed at Mach 5, and data becomes available for Mission Control 
evaluation at Mach 3.5. Each probe provides two independent measurements. Kalman filter processing 
begins at Mach 2.5 and an altitude of about 85,000 feet. Drag altitude processing ends once barometric 
altimeter processing begins. Barometric altimeter processing is inhibited between Mach 1.6 and Mach 1.1 
(the Mach jump region). 

PASS Kalman filter processing of MLS range, azimuth and elevation data usually begins at about 17,000 
feet. Once MLS is acquired, PASS stops processing TACAN and barometric altimeter data and shifts 
from maintaining three state vectors to one state vector. Lor a landing site not equipped with MLS, PASS 
processing of TACAN stops at an altitude of 1,500 feet, and baro processing continues until 500 feet. BPS 
does not process MLS, and will process TACAN and baro data all the way to landing. 

Selected radar altimeter data is available to the crew for situational awareness from 5,000 feet until 
landing. It is not processed in a Kalman filter, due to a lack of accurate terrain models for Shuttle landing 
sites. 

Emergency Use Of Uncertified, Single String GPS During Entry 

During the flight test phase (prior to the August 2002 certification, only one MAGR/S on each orbiter), 
flight rules were developed permitting use of selected MAGR/S state vectors under the following 
emergency conditions: 

• Use in place of a voice delta state uplink during entry. Complexity of the voice delta state uplink 
makes it more risky than incorporating uncertified GPS data. 

• Avoid scenarios (low ceilings at landing, on-board and/or ground station TACAN and MLS failures) 
that could result in a high-risk crew bailout and loss of vehicle. 

• Enable Mission Control to resolve dilemmas between redundant navigation sensors (HAINS IMUs, 
barometric altimeters, TACANs, MLSs). This does not require incorporating GPS states into the Shuttle 
navigation software (Pigure 15). 

During training simulations. Mission Control training supervisors regularly fail various systems on the 
Shuttle to train flight controllers on anomaly recognition, resolution, and procedural work-arounds. 
Pailing a navigation sensor involves either presenting the Shuttle computers with erroneous data that 
prevents them from using the sensor or simply turning off the unit. Simulation experience in Mission 
Control has proven that a single functioning GPS receiver greatly aids flight controllers in identifying and 
isolating suspect legacy navigation units. Regularly failing the GPS receiver prevents flight controllers 
from becoming too dependent on GPS for anomaly identification and resolution. 
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Figure 15 - The Shuttle GPS single string (one GPS receiver) configuration greatly 
aids detection and isolation of suspect legacy navigation sensors by Mission Control. 


Entry Navigation I n The GPS Era 

For the first several operational flights, selected MAGR/S data will not be taken into the Shuttle 
navigation software between the deorbit burn and the acquisition of ground radar tracking (around 
140,000 feet, the TACAN acquisition altitude). This will permit a comparison of MAGR/S data with 
ground tracking before incorporation. Once operational experience with the three string system has been 
obtained, navigation system updates with GPS will resume after the deorbit burn and continue through 
MLS acquisition (or landing if MLS is not available). However, selected MAGR/S states do not have to be 
continuously incorporated into Shuttle navigation to support entry and landing. 

Drag altitude measurements will still be processed to bound error growth in the event of GPS outages or 
IMU failures. It is expected that drag measurements will have little impact on the navigation state when 
GPS is incorporated in the automatic mode. 

Space Shuttle navigation software will continue to process barometric altimeter and MLS data (in the 
PASS) after TACAN has been replaced by GPS. Whenever selected barometric altimeter measurements 
are available for processing by the PASS and BFS GPCs, they will also be processed by the MAGR/S 
Kalman filter. This allows the GPS units to determine the bias on the barometric measurements during 
four satellite tracking. In the event of less than four satellite tracking, calibrated barometric altimeter 
measurements will help maintain accurate MAGR/S states. 

GPS states will be an important source of data for Mission Control during emergency landings at sites 
where there is no ground radar tracking capability. 
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During entry. Mission Control in Houston will have an open line to the GPS Master Control Station 
(MCS) at Schriever Air Force Base, Colorado. Mission Control will be informed of any GPS satellite 
integrity issues that arise. The crew has the ability to command the MAGR/S units not to track specified 
GPS satellites for measurements. 

Single-String GPS Use After Certification 

The single GPS receivers on Discovery and Atlantis will be used as a navigation source during entry, but 
TACAN data will continue to be processed. This will enhance safety of flight and provide crew and 
Mission Control personnel with operational experience and confidence building in GPS before the use of 
three string GPS on Endeavour. Post certification, single string use of GPS during entry has been 
proposed as follows: 

• Those scenarios listed under emergency use of uncertified, single-string GPS. 

• Use as an extra level of redundancy in case of TACAN navigation sensor and/or ground station failures 
(TACAN, radar). 

• Provide redundancy in the event of ground radar tracking station failures. 

• Avoid early mission termination due to TACAN failures while on-orbit. 

• Source of vectors to support emergency deorbit. 

• On-board navigation updates on-orbit, when not performing translational maneuvers or rendezvous. 

• Permit a launch in the event of a navigation aid (TACAN, barometric altimeter, MLS) failure on the 
pad. 

The single-string configuration also provides additional protection when using TACAN stations of 
questionable calibration at emergency landing sites. TACAN stations used by the Shuttle for landings at 
the Kennedy Space Center, Edwards Air Force Base, and Northrup Strip (New Mexico) are calibrated to 
tighter NASA standards. Emergency landings at other sites, in the United States and around the world, 
require use of TACAN stations that have been calibrated to standards that are not as tight. Single-string 
GPS will provide more accurate navigation at these sites than TACAN, and it is the technique that 
Mission Control prefers. TACAN will still be available in the event the Shuttle computers cannot use 
single-string GPS data. 

Operational Ramp-Up to Single String Use During Entry 

The operational ramp-up to use of single string GPS during entry will occur over five flights starting after 
the return to flight ( Discovery , STS-114, July-August 2005). The point on each flight at which GPS 
incorporation will begin is defined: 
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1. GPS to BFS after radar acquisition (-140,000 feet, - Mach 6). 


2. GPS to the BFS after the deorbit bum. 

3. GPS to PASS after radar acquisition (-140,000 feet, - Mach 6). 

4. GPS to PASS after the deorbit burn. 

5. GPS to PASS and BFS after the deorbit burn. 

Operational ramp-up for single string use should be complete before the first flight of three-string GPS 
(no TACAN) on Endeavour. 

Differential GPS and the Space Shuttle 

Although the MAGR/S does have a differential GPS capability, there are currently no plans to replace 
MLS with differential GPS. Use of a MAGR/S to perform differential GPS, and replace the Microwave 
Landing System, was discussed, but not pursued due to the continued viability of MLS, and the difficulty 
of using the five-channel receiver to support the differential application. Studies have shown that 
differential GPS would provide little accuracy improvement over the current MLS system. 

A differential GPS capability would have required adding Very Fiigh Frequency (VFLF) antennas to the 
orbiters, with adequate visibility to support landing, as is done with TACAN antennas. After TACAN 
replacement, the GPS antenna pairs would occupy two of the positions formerly occupied by TACAN 
antenna pairs. There are technical issues with placing omni-directional VFFF antennas under the thermal 
protection tiles in spots formerly occupied by Ku Band MLS antennas. New antenna positions and 
associated holes in the orbiter structure for cabling would have been required for the VHF antennas. 
Drilling more holes in the vehicle for antenna placement is not desirable. 
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8. Other GPS Receivers On The Space Shuttle 


Several civilian GPS receivers have flown in the Shuttle payload bay in support of experiments and on 
deployed payloads (Table 1, page 21). 


Relative GPS Demonstrations 

Perhaps the most notable were relative GPS navigation experiments conducted on two Shuttle missions 
that deployed and retrieved scientific payloads. These experiments were intended to investigate the use 
of GPS for spacecraft rendezvous. One was conducted jointly with the European Space Agency as a risk 
mitigation effort in support of the Automated Transfer Vehicle under development for the ISS Program. 
Flight results may be of importance to future development of relative GPS filters for rendezvous and 
formation flying. 

On STS-69 ( Endeavour , September 1995) [12,14,15] the Wake Shield Facility (WSF) free flyer had an Allen 
Osborne TurboStar GPS receiver. The orbiter Endeavour was equipped with the Collins five channel 3M. 
The Orbiting Retrievable Far and Extreme Ultraviolet Spectrometer Shuttle Pallet Satellite (ORFEUS- 
SPAS) payload deployed and later retrieved on STS-80 ( Columbia , November-December 1996) was 
equipped with Laben Tensor (nine channel) and Actel GPS receivers [13]. The source of orbiter data 
during STS-80 was a Trimble Advanced Navigation System (TANS) Quadrex (six channel) receiver. 

GPS pseudorange data from receivers on the deployed payloads and the orbiters were processed in 
laptop computers on the Shuttle during the flight, and on the ground both during and post-flight. The 
laptops contained Kalman filters that provided a relative navigation solution. 

During the STS-69 test, poor satellite visibility resulted in few periods where both receivers were tracking 
a set of four common satellites needed for accurate relative navigation. Although a power supply failure 
in the TurboStar prevented relative navigation during the rendezvous, data was available from other 
periods of WSF activity. Lessons learned from STS-69 data processing were applied to the STS-80 relative 
navigation experiment development [15]. 

On STS-80, the SPAS attitude during the approach of the Shuttle was controlled so that GPS antennas on 
both vehicles would see the same satellites. This helped facilitate common tracking of at least four 
satellites. In-flight and initial post-flight results were less than satisfactory due to issues involving 
receiver clock drift, frequent acceleration from Shuttle jet firings, unmodeled acceleration compensation, 
residual edit thresholds and an error in the antenna to center of gravity offset computation. Better 
performance was obtained after the relative filter and measurement processing was modified after the 
mission [13]. Relative position accuracy was comparable to Shuttle on-board relative navigation 
performance, but the relative velocity performance was poor compared to the Shuttle. Processing of 
carrier phase measurements would have improved relative GPS velocity. 
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Lack of insight into the 3M, TurboStar, Tensor and Quadrex GPS receivers made integration, data 
processing and data analysis more difficult. In addition, lack of insight into algorithms (particularly 
those associated with clock steering) made development of the laptop based relative GPS navigation filter 
more challenging. 


Scientific Payload Support 

The flight of Endeavour on STS-99 in February of 2000 carried the Shuttle Radar Topography Mission 
(SRTM) payload. Two Blackjack receivers (which were originally designed for space applications) on the 
payload provided GPS data to be processed post-flight to provide highly accurate positioning data [17]. 
Due to the critical nature of the mission. Shuttle MAGR/S, TDRSS Doppler and Shuttle IMU data served 
as an independent back-up to the Blackjacks. A spare MAGR/S was carried on the flight in a mid-deck 
locker and an in-flight MAGR/S change-out procedure was developed for the crew in the event that the 
primary MAGR/S failed. The Blackjack met the 60 cm position accuracy requirement needed for post¬ 
flight processing of SRTM data. 


Preparation for Future Autonomy Demonstration 

The Low Power Transceiver (LPT) flew in the cargo bay of Columbia on STS-107 [104-106]. A 
collaborative effort between NASA and industry, the LPT demonstrated both GPS navigation and 
communication capability through TDRSS and the Space Tracking and Data Network (STDN). The 
NASA Goddard developed GPS Enhanced Orbit Determination Experiment (GEODE) software [107] was 
used in the LPT to provide high accuracy orbit determination. Data was downlinked during the mission 
for evaluation. Future applications of the LPT include autonomous navigation, spacecraft 
communication, range safety for space based ranges and satellite formation flying. 
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9. Shuttle Space I ntegrated GPS/1 NS 


As GPS receivers became smaller, navigation system developers began envisioning the placement of GPS 
receivers directly inside Inertial Navigation System (INS) units, which themselves contain an Inertial 
Measurement Unit. By 1995, Embedded GPS/Inertial Navigation System (or "Embedded GPS/INS" or 
"EGI") units entered production for atmospheric flight and terrestrial applications. The EGI provides 
cost, size and weight savings over previous navigation systems which consisted of separate avionics 
boxes. Since GPS data would not have to be sent outside the receiver to be processed, a central Kalman 
filter could incorporate GPS measurements corrected for S/A effects, as well as other measurements 
(barometric altimeter, Doppler radar, radar altimeter). 


Tightly Coupled I ntegration 

The tightly coupled integration scheme of the EGI overcomes data latency issues with previous 
architectures. Less latency in aiding permits the carrier loops to be aided and speeds up satellite 
acquisition. The incorporation of all sensor measurements in one filter with high integration rates 
provides a much more accurate solution than separate box architectures. In addition, ground and flight 
testing has shown that the tightly coupled EGI blended solution has far superior performance under less 
than 4 satellite tracking conditions than a stand alone GPS receiver [86]. Since an aircraft or missile is 
subjected to continuous specific force (due to thrust, lift and drag), the Kalman filter can obtain estimates 
of sensor errors as maneuvering makes sensor errors visible to the filter through position and velocity 
errors. Continuous calibration of the inertial sensors permits an accurate position, velocity and attitude 
solution during GPS outages (such as jamming). This also allows manufacturers to use lower cost inertial 
sensors. The Kalman filter also permits alignment of inertial sensors much faster than INS systems 
without GPS [108]. These factors, along with cost, size, power and weight savings made EGI units an 
attractive alternative to legacy navigation systems consisting of multiple line replaceable units. 

Three test flights of EGIs were conducted to determine if such a device could be used in space with a 
minimum number of software modifications (Table 1, page 21). The first EGI unit to fly was the Litton 
LN-100G, with a Collins GEM III five channel SEM-E form factor GPS receiver. The GEM III contained 
software modified for space use, based on GEM III Link 010, produced by Collins to support the Army 
Tactical Missile System program. The Litton EGI flew on missions STS-81 ( Atlantis , January 1997) and 
STS-86 ( Atlantis , September-October 1997) to provide data gathering for NASA's X-33 and X-34 programs. 
A Honeywell H-764G EGI, with the same type of GEM III receiver as was flown in the Litton unit, flew 
on STS-84 ( Atlantis , May 1997). 


Shuttle Space I ntegrated GPS/1 NS 

In September of 1996, Honeywell was awarded a contract by NASA for the Space Integrated GPS/INS, or 
SIGI. SIGI was to be a common NASA navigator, based on the H-764G EGI, to be used by both manned 
and unmanned space vehicles [3]. The Shuttle version of SIGI, intended to replace the MAGR/S and the 
HAINSIMU, contained the same Collins GEM III GPS receiver that was previously mentioned. 
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Whereas the MAGR/S was integrated into the Shuttle avionics system as a "navigation system," the 
Shuttle SIGI was to be integrated as both a sensor and a navigator. The SIGI blended state vector solution 
was processed by the Shuttle PASS and BFS flight software using the same software used to process 
MAGR/S data. GPS receiver data and control commands were kept the same as MAGR/S. This 
integration concept was known as "MAGR/S transparency," and minimized the amount of changes to the 
Shuttle flight software. 

The Shuttle flight software requires a source of IMU data (integrated attitude rates, change in 
accumulated sensed velocity). SIGI integrated attitude rates and change in accumulated sensed velocity 
data were to be processed by the PASS and BFS computers as sensor data, in the same way that FFAINS 
IMU data were processed. 

The original inertial sensor integration concept was "FFAINS IMU transparency," an attempt to avoid 
changes to the Shuttle flight software. The SIGI strapdown inertial instrument data was to be processed 
within the SIGI to look like stable member HAINS IMU data, before being passed to the PASS and BFS 
GPCs. However, the transparency option would have made it impossible for Mission Control to identify 
and take action on suspect gyros and accelerometers. As a result, the HAINS IMU transparency option 
was abandoned. More changes were made to the SIGI software to support the Shuttle missionization 
than were expected. 

The stable members of the three HAINS IMUs are skewed with respect to each other, so that Mission 
Control personnel can identify suspect gyros and accelerometers if only two HAINS IMUs are operating. 
With the strapdown configuration of the SIGIs, the axes of the inertial instruments in all three SIGI units 
would be parallel, making it difficult for Mission Control to identify suspect inertial sensors if only two 
SIGIs were operating. Mounting the strap-down SIGI units in a skewed configuration was not feasible; 
therefore four SIGI units on each orbiter were needed. As a result, plans were made to carry four SIGIs 
on the orbiters, rather than three. 


Shuttle SI Gl Ground and Flight Test Results 

SIGI radiation testing resulted in the replacement of a static random access memory chip. Shuttle SIGI 
flew on Shuttle missions 86, 89, 91, 95, 88, 96 and 103 from September of 1997 to December of 1999. A 
cable splitter after the radio-frequency combiner enabled the SIGI to use the same antennas, pre-amps 
and combiner as the MAGR/S. SIGI commanding and data recording was conducted by a crew operated 
laptop computer. Numerous changes were made to SIGI software based on ground and flight test 
results. Closed loop lab testing of SIGI units using a signal generator that involved both the GPS and 
IMU functions of the devices was challenging. 

During frequent flights of military aircraft the maneuvering, continuous specific force (engine thrust, lift 
and drag) and processing of GPS measurements permits the EGI Kalman filter to accurately calibrate the 
gyros and accelerometers. While the SIGI strapdown IMU data was reliable, blended filter performance 
was frequently questionable and much of the software modification effort was aimed at the blended 
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filter. The short periods of flight during which the shuttle experiences specific force (lift, thrust and drag) 
while maneuvering (ascent and entry), coupled with months between flights rendered the reliability, 
stability and quality of blended Kalman filter inertial sensor error estimates doubtful. 

For the Shuttle to get into a precise orbit the IMUs must be accurately aligned on the launch pad. Stable 
member HAINS IMUs are aligned by using the sensed Earth rotation and gravity direction. The platform 
is oriented in various directions so that each of the accelerometers can calibrate against the gravity vector 
and the gyros can calibrate against Earth rotation. With all of the advantages of a space missionized EGI, 
preflight strapdown system alignment presented a challenge. There were three opportunities at the 
Kennedy Space Center to make observations when the vehicle was at different orientations: the Orbiter 
Processing Facility, the Vehicle Assembly Building, and the launch pad. The difference in orientation at 
the three locations was not adequate to get a good separation of the alignment variables. 

Since the HAINS IMUs were projected to be operational through 2010, replacement of the HAINS IMUs 
and MAGR/S units by SIGIs was deferred, and the project was placed on the shelf after the STS-103 test 
flight ( Discovery , December 1999) was conducted. 
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10. X-38/ Crew Return Vehicle 


In the mid 1990s, NASA JSC began to develop the X-38, a prototype of a proposed CRV for the 
International Space Station. The CRV was to provide an emergency return capability for the ISS crew in 
the event of a medical or spacecraft emergency. GPS was a key part of the X-38 avionics system [2]. 
Although the X-38 project was canceled in the spring of 2002, much GPS work was performed and 
important lessons were learned. 


V-201 Flight Test 

At the time of project cancellation, the X-38 team was preparing the V-201 vehicle for an unmanned test 
flight. This test involved V-201 deployment from the Shuttle payload bay using the Remote Manipulator 
System, followed by execution of a deorbit, entry and landing profile. V-201 would have been equipped 
with three SIGI units (to meet the one fault tolerant requirement). The operational CRV (human rated), 
which would have been taken to the ISS on a later Shuttle flight, was to have had four SIGIs (to meet the 
two fault tolerant requirement). 


X-38 Design 

To lower development costs, the X-38 used the same outer mold line as the Martin Marietta X-24A lifting 
body, which was tested from 1969 to 1971 (Figure 16) [109]. The lifting body had a higher lift to drag 
ratio than a lifting capsule (such as Apollo, Soyuz, and Gemini), and therefore provided a less strenuous 
entry (i.e. lower g forces), which is an important consideration when returning injured or sick 
crewmembers from orbit. A lifting body also provided more entry cross and downrange maneuvering 
capability than a lifting capsule, which enhanced the ability of the CRV to quickly return a crew to an 
appropriate landing site. Rather than a high speed landing on a runway, as was done by the lifting 
bodies tested at Edwards from 1963 to 1975, a 5,500-square foot steerable parafoil was used (Figure 17). 
Elimination of runway landing also lowered development costs, and increased the number of possible 
ground landing sites, which in turn reduced the time required to return crewmembers from the ISS [110]. 



Figure 16 - The Martin Marietta X-24A at 
Edwards Air Force Base, 1968. 
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CRV GPS Unit 


The X-38 used the same type of SIGI unit and Force 19 GPS 
receiver as the ISS, but some changes to the X-38 SIGI 
software were made later in the program. However, unlike 
the ISS SIGI, the strapdown IMU measurements and 
blended filter data were required from the beginning. 
High accuracy IMU data was critical for performing guided 
lifting entry at hypersonic velocities to achieve a precision 
landing. The Force 19 would provide the same position, 
velocity and attitude data as was done for ISS. Leveraging 
on the ISS GPS attitude development effort would lower 
development and integration costs. GPS attitude 
determination was also believed to be a less costly solution 
to the initial attitude determination problem than star 
trackers, which would require modification to the X-38 
structure. Four GPS antennas were placed on the top of the 
X-38 to support attitude determination (Figure 18). 



Figure 17 - X-38 prototype V-132 
during the fifth drop test at 
Edwards, March 2000. 


Four Upper GPS 



Figure 18 - X-38 GPS antennas and camera bore sights for the proposed V-201 
unmanned test flight. Only camera bore sights in the plane of the figure are shown. 
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CRV SI Gl Ground and Flight Testing 


Drop Tests 

Prototype X-38 vehicles were dropped from a 
NASA B-52B at Edwards AFB to test the landing 
guidance, navigation, control, and parafoil 
systems (Figure 17) [110]. These vehicles used the 
H-764G EGI unit intended for atmospheric flight, 
rather than the SIGI (space) version of the H-764G 
(Figure 19). The EGI integration and operation on 
the X-38 was smoother than the CRV SIGI 
integration, as the EGI was being used in an 
atmospheric application, for which it was 
originally designed. 

Test Flights on the Shuttle 

The CRV SIGI flew in a data collection mode on tv 
the radio-frequency combiner enabled the SIGI to use the same antennas, pre-amps and combiner as the 
Shuttle MAGR/S. Attitude determination was not exercised. Examination of GPS satellite tracking by the 
MAGR/S and CRV SIGI units on Shuttle flights also led to the addition of the lower antenna on the X-38 
(Figure 18). Having both upper and lower GPS antennas (as was done for the Shuttle MAGR/S receivers 
and the legacy Shuttle TACAN units. Figures 6 and 7, page 65) facilitated successful tracking at all 
attitudes on-orbit and during entry when not in the plasma region. 


Table 7 - X-38 SIGI Flight Test Program on the Shuttle 


Shuttle 

Mission 

Year 

Orbiter 

Primary Mission 

100 (6A) 

2001 

Endeavour 

Installed ISS robotic arm 

Raffaello Multi-Purpose Logistics Module 

108 (UF-1) 

2001 

Endeavour 

ISS crew exchange 

Raffaello Multi-Purpose Logistics Module 



Figure 19 - X-38 drop tests were conducted 
at Edwards Air Force Base. 


Shuttle missions (Table 7) [3]. A cable splitter after 


GPS signal tracking is subjected to a plasma region during entry. On STS-100, plasma effects impacted 
Force 19 tracking starting at about 270,000 feet, and continuous tracking of four satellites ceased at 
around 240,000 feet. Continuous four-satellite tracking did not resume again until about 130,000 feet. 
The inertially aided MAGR/S receiver performed much better. For the follow-on STS-108 flight, the SIGI 
was modified so that the Force 19 could use aiding data to help reestablish satellite tracking after plasma. 
As a result, continuous four satellite tracking was regained by an altitude of 210,000 feet [3]. 
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Additional Testing 


Issues observed on the STS-100 mission 
prompted testing of the CRV SIGI on a NASA 
Beechcraft Beech 200 Super King Air at the 
Dryden Flight Research Center (Figure 20). 
This was the X-38 SIGI Atmospheric Flight 
Test, or X-SAFT. Two CRV SIGIs were carried, 
and one H-764G EGI and one Ashtech Z-12 
differential GPS receiver were on-board for 
comparison with the SIGIs. The first phase of 
13 test flights (August-October 2001) was 
performed to assess position and velocity 
determination. For the second phase of 6 test 
flights (February-May 2002), four GPS antennas 
were placed on the King Air to support attitude 
determination tests. The tests were useful for 
comparing side-by-side performance of two 
identical SIGI units (for redundancy 
management architecture decisions), validation 
of lab test equipment, and check-out of 
procedures, data collection and commanding 
software. The test flights were unable to 
duplicate performance issues that occurred on- 
orbit during the Shuttle flights of CRV SIGI. 



Figure 20 - NASA personnel conducted CRV 
SIGI tests in a Dryden Flight Research Center 
Beechcraft King Air. 


Resolving the SI Gl Attitude I nitialization I ssue 

Solving For Attitude 

Requirements for the contingency departure from ISS scenario dictated that the CRV avionics system 
must be able to solve for position, velocity, and attitude without a data transfer from Mission Control 
(Houston or Moscow) or the ISS computers (i.e. a SIGI cold start must be performed). To support a re¬ 
contact avoidance burn 22.5 minutes after departure from the ISS, cold start completion was needed soon 
after separation. Lab testing of the Force 19 indicated that it could provide position and velocity 
relatively quickly after a cold start. However, lab testing also revealed that the receiver could not always 
provide GPS derived attitude under cold start conditions in time to support the re-contact avoidance 
burn, due to the time required to solve for carrier phase integer ambiguities. 

Finding a Way to Compute Attitude Quickly 

Alternate methods of SIGI attitude initialization were studied. One option involved adding 
magnetometers to the CRV, but technical problems prevented this. A digital camera system had been 
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included in the CRV design to provide the crew with situational awareness during undocking and 
separation from the ISS, until the CRV was clear of ISS structure, and could be adapted to perform an 
initial attitude determination function. This system was slated for testing on the X-38 V-201 test flight, 
and software and procedure development was begun so that the optical attitude determination feature 
could be tested on that flight. 

The Camera System 

Five cameras were to be mounted on the top of the Descent Propulsion System (DPS), and two on the 
bottom (Figure 18). Earth limb and nadir sightings, coupled with inertial rate data from the SIGIs, would 
be used to compute an initial attitude estimate. On the CRV, the crew could quickly perform the 
sightings before or after separation from the ISS. Attitude estimates produced by this method were 
deemed accurate enough to support the collision avoidance bum. In addition, the attitude estimates 
would speed up the Force 19 integer ambiguity resolution process, which would lead to more timely GPS 
attitude determination. 

Camera Tests For V-201 

For the unmanned V-201 flight. Mission Control would perform the Earth limb and nadir sights on video 
transmitted from the X-38 to test the attitude determination algorithm. Horizon sensors were also 
mounted on the DPS of the V-201 vehicle to cross check the digital camera attitude solution. 


V-201 SIGI Operations Concept 

For the unmanned V-201 X-38 test flight, the three CRV SIGIs were to be activated and checked out while 
the X-38 was still in the orbiter payload bay. The Shuttle onboard star trackers and the MAGR/S, along 
with TDRSS and ground radar tracking were to be used to check SIGI attitude, position and velocity. 

After deployment, X-38 horizon sensors were to be used to check the GPS attitude computed by the 
SIGIs. GPS attitude determination was to be turned off before entry, and the SIGIs would continue to 
determine attitude based on integrated rate measured by the SIGI strapdown IMUs. SIGIs were to 
continue to perform position and velocity determination until landing. 

A back-up navigation function was designed into the X-38 software in the event of SIGI problems. Back¬ 
up navigation was to be initialized using a selected SIGI blended position and velocity vector. SIGI 
strapdown IMU sensed delta-velocity data was to be continuously used to propagate the backup state 
vector. Starting at an altitude of -80,000 feet (-Mach 2.5), barometric altitude data from the Flush Air 
Data System was to be incorporated by backup navigation to control vertical position errors. Backup 
navigation could be reinitialized using a selected SIGI blended state vector if Mission Control personnel 
deemed that errors in the backup state vector were excessive. 
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To support landing, a radar altimeter was to provide more accurate altitude than SIGI from 5,000 feet 
through touch down. Further definition of navigation architecture and procedures for the operational 
CRY was to be made based on V-201 flight results. 


98 of 118 



11. Rationale Behind a Notional Shuttle GPS Receiver Upgrade 


Prior to the decision to retire the Shuttle by 2010, consideration was given to replacing the Space Shuttle's 
mid-1990s vintage 5-channel receiver with a more modem, all-in-view tracking receiver. This chapter 
details some of the ways advanced GPS technology could have been leveraged to improve Shuttle 
navigation, and some reasons why advanced GPS technology would not have changed some aspects of 
Shuttle navigation. 


The current receiver represents an early 1990s technology level. Although it has flown on the Shuttle 
since 1996, and been certified for use during flight, newer GPS units, GPS satellites and augmentation 
systems are entering (or will soon enter) service with more advanced capabilities. Some of these 
capabilities could be leveraged to improve Shuttle navigation and safety, particularly if new automation 
or autonomy requirements emerge (Figure 21). A study would be required to determine which advanced 
capabilities would provide benefit to the Shuttle Program. Identification of candidate replacement 
receivers would be contingent on when new satellite navigation capabilities are introduced, and when 
receivers that take advantage of those new features are available. This section discusses several ways in 
which GPS could be applied to the Shuttle, but not all of the concepts mentioned are desirable for the 
vehicle. 


Legacy Sensors 


Ascent 


Orbit Absolute Nav 


Orbit Relative Nav 


Entry & Landing 


•3 IMUs 
• Ground Radar 


■3 IMUs 

■ 2 Star Trackers 


• 2 Star Trackers 

• Ku Band Radar 


• 3 TACAN & 1 
GPS or 3 GPS 



• Facilitates Autoland 

• Lower Minimum Ceilings 

• Improved Integrity 

• Safer Emergency Landings 


Modern GPS Receiver 


Figure 21 - Legacy Navigation Sensors By Flight Phase, With Potential Advantages of a Modern Receiver. 


99 of 118 



Receiver Recovery 


Modern GPS receivers can track 12 or more GPS satellites at a time. This greatly speeds up state 
determination after a power cycle or receiver software reset, and reduces the likelihood that difficult 
tracking conditions will result in unavailability of the GPS navigation solution. This would provide a 
performance improvement over the current five channel Shuttle GPS receiver. 


Loss of Service 

The five channel unit certified for use on the Shuttle uses four channels to obtain GPS measurements, and 
a fifth for ephemeris collection, measurement collection for correction of ionospheric errors, tracking 
channel calibration and satellite acquisition. New satellites needed to maintain track of an optimal set of 
four are acquired sequentially. Under difficult tracking conditions (multi-path, antenna obscuration, 
satellite line-of-sight off of the antenna gain pattern), multiple satellite switches could fail or be delayed, 
resulting in less than optimal satellite geometry or less than four satellite tracking for extended periods of 
time. 

In some cases during testing, the receiver's estimate of its position accuracy exceeded a Shuttle computer 
GPS quality assurance test limit, which would have prevented the Shuttle computers from using position 
and velocity data from that receiver. The length of the GPS outages varied. An extensive ground test 
effort was conducted to ensure that loss of a GPS receiver during entry due to this condition would not 
compromise safety of flight. 

An all-in-view receiver (capable of tracking 12 or more satellites at a time) would be more capable of 
providing a navigation solution under difficult tracking conditions. 


New GPS Signals 

Current GPS satellites broadcast two military signals and one civilian signal, all of which can be tracked 
by the Shuttle GPS receiver. New GPS satellites, which will be launched in this decade, are the Block IIR- 
M and Block IIF series [111, 112], 

In addition to the three legacy signals, the Block IIR-M satellites will broadcast two new authorized user 
signals, a new civil signal, and all signals will be broadcast at a higher power level than the previous GPS 
satellites (Figure 22). The Block IIF satellites, will broadcast those signals transmitted by the Block IIR-M 
vehicles, as well as a third civil signal to support safety-of-life applications, such as aircraft. The current 
Shuttle receiver will be able to track legacy signals transmitted by the Block IIR-M and Block IIF satellites, 
but a new GPS receiver will be required to take advantage of the additional signals and the improvement 
they provide to navigation integrity. Early in the next decade, the next generation GPS satellite, GPS III, 
may be entering service. This satellite and its new architecture may possess newer signals, enhanced 
reliability and accuracy. 
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Satellites 


Block IIR-M Satellites 


Block IIF Satellites 


Galileo 


GPS III 
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• Civil signal on L2 
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• First launch 2005 


• L5 safety of 
life signal 

• Longer lifetime 
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• European controlled 
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• Projected full 
operational 
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support the long term 
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• First launch 2013? 


Space or Ground Based Augmentation 


WAAS 

• Satellite broadcast 

• Enhances GPS accuracy & 
integrity in North American 
airspace 

• Ranging, differential 
correction and integrity 
signals 

• Supports take-off through 
CAT I approach 

• Initial Operating Capability 
7/10/2003 

• Final capability -2008 


EGNOS 

• European equivalent 
of WAAS 

• Monitors GPS, GLONASS 
& Galileo (future) 

• Covers Europe, with possible 
expansion to Africa 

• Safety of life certified -2006 


Future WAAS/EGNOS 
Compatible Systems 

• Japan 

• India 

• Others 


JPALS 

• Ground or ship broadcast 

• High accuracy & integrity 

• CAT I, II & III all weather 
approaches 

• Naval and land versions 
under development 

• Naval version will support 
automated carrier landings 

• Civilian version (LAAS) 
under development 


Figure 22 - Upcoming Enhancements to Global Navigation Satellite Systems 


Receiver Autonomous I ntegrity Monitoring and Satellite Based Augmentation 

The level of GPS navigation solution accuracy, availability and continuity are important. In addition, the 
integrity of the navigation solution, whether or not it can be trusted, is critical [113]. The integrity of the 
GPS navigation solution is dependant on the on-board GPS receiver, the GPS satellites and the GPS 
ground support infrastructure. 

Currently, the Shuttle Program is dependent on the GPS Master Control Station (MCS) for notification of 
malfunctioning satellites. If the MCS cannot set the satellite health bit or change the satellite GPS signal 
to be non-trackable, the MCS would pass word of the malfunctioning satellite to Mission Control. Based 
on Mission Control instructions, the crew would perform a data entry into a Shuttle computer display to 
instruct the GPS receivers to ignore the unhealthy satellite. 

The all-in-view tracking capability of modem receivers facilitates the use of Receiver Autonomous 
Integrity Monitoring (RAIM), which detects anomalous GPS signals and identifies suspect GPS satellites, 
facilitating exclusion of their measurements from state vector determination. The availability of RAIM 
would provide a level of protection against spurious GPS signals that is not available today with the 
Shuttle's five-channel receiver. 

While RAIM provides protection against suspect satellites, there may be times when a receiver is tracking 
an insufficient number of GPS satellites with suitable geometry to support RAIM. Satellite or ground 
based augmentation using ground monitoring stations can provide a higher level of "real time" integrity 
protection than a stand-alone GPS receiver employing RAIM [113]. 
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The U.S Wide Area Augmentation System (WAAS) and European Geostationary Navigation Overlay 
Service (EGNOS), which are satellite based augmentation systems (the augmentation signals are 
broadcast by satellites other than the GPS satellites), will provide GPS satellite integrity information to 
those GPS receivers capable of receiving WAAS and EGNOS signals (Figure 22) [114]. WAAS and 
EGNOS navigation payloads on geostationary satellites broadcast ranging, differential correction and 
satellite integrity signals. This will enable receivers to exclude satellites of questionable quality. The 
additional ranging signals will improve solution quality and availability. 

WAAS covers most of North America with GPS corrections and integrity signals, while EGNOS 
broadcasts GPS and Global Navigation Satellite System (GLONASS) related data to Europe. EGNOS 
could be expanded to cover Africa, and will eventually broadcast Galileo related data. Other countries 
such as Japan and India are considering building systems that perform the same function as, and are 
compatible with, WAAS and EGNOS. 

Receiver based RAIM and access to integrity data from satellite based GPS augmentation systems would 
permit a modem GPS receiver to exclude a questionable satellite in an autonomous manner, more 
quickly than can be done with the legacy five channel receiver. 


Shuttle Autoland Using Ground Based GPS Augmentation 

The Shuttle was designed with an autoland system, which has been upgraded over the years [115, 116]. 
However, a completely automatic landing has never been attempted, and the capability is a back-up 
flying mode for contingencies. 

The Shuttle's MLS is an integral part of the Shuttle's autoland capability. It has been successfully used to 
support piloted landings since the beginning of the Shuttle flight program in 1981 [117]. The Shuttle MLS 
system is different than that used to support civil aviation, and is only available at six Shuttle landing 
sites.* The Shuttle has a much steeper glideslope than aircraft. Over the long term, there are difficulties 
in maintaining the legacy MLS on-board and ground equipment. Multi-path and coverage issues are also 
of concern with MLS support for autoland. 

If automated landings of either a crewed or uncrewed Shuttle are desirable in the future, use of a ground 
based GPS augmentation system (augmentation signals are broadcast by a ground station) employing the 
differential GPS concept may be preferable over MLS. A ground-based augmentation system could 
provide a navigation solution of sufficient accuracy and integrity, provide more operational flexibility in 
landing site selection, and enhance safety margins. 


* Within the Shuttle Program, the name Microwave Scanning Beam Landing System (MSBLS) is often used to 
differentiate the Shuttle system from the civil and military aviation Microwave Landing System. 
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The military Joint Precision Approach and Landing System (JPALS)* will provide high accuracy, high 
integrity differential GPS navigation to support precision landing in all weather conditions [5, 118-123]. 
Tests of a prototype JPALS system have already supported automated F/A-18 carrier landings and 
Unmanned Aerial Vehicle (UAV) tests [119, 121]. JPALS will play an important role in future UAV 
operations [122]. One set of JPALS ground equipment could service all the runways at a landing site, 
while the legacy MLS equipment has to be positioned at each runway. This would ensure availability of 
precision landing capability no matter which landing site runway was selected. 

Use of JPALS would require a new GPS receiver. The legacy receiver was not required to, nor does it 
support, precision landing using GPS augmentation. 


Weather Minimums For Landings 

Use of an all-in-view receiver with JPALS and RAIM may also permit reduction of minimum ceilings, 
and provide more safety margin for emergency landings, whether they are piloted or automated. 


Simplification of Shuttle Navigation Procedures 

A more capable and robust GPS receiver could lead to the simplification of Shuttle on-board and Mission 
Control navigation procedures. However, any such simplification would have to be proceeded by an 
extensive analysis of current procedures, program requirements and flight rules. Furthermore, each 
proposed change should be examined to determine if the payback in terms of life cycle costs and risk 
reduction justifies the change. 

The first measurement processed during entry is drag altitude, computed using Inertial Measurement 
Unit data and an atmosphere model. Drag altitude introduces an expected level of altitude error into the 
Shuttle navigation state, but bounds altitude errors that are common to inertial navigation systems. All- 
in-view tracking, RAIM and satellite integrity signals from satellite-based augmentation could eliminate 
the need for drag altitude measurement processing. 

A ground computed correction to the Shuttle on-board navigation state, called a delta state update, is a 
backup to the on-board navigation system. This capability requires two ground radars, a good Mission 
Control solution of the Shuttle state vector, and a commanding capability to put the delta-state into the 
Shuttle computers. Given the integrity functions available to more advanced GPS receivers (WAAS, 
JPALS, RAIM, more signals), dependence on the delta state backup capability could conceivably be 
reduced. 


A civilian equivalent, the Local Area Augmentation System (LAAS), is under development. 
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Barometric altimeters provide altitude measurements for Kalman filter processing by the Shuttle primary 
and backup computers. Given that barometric measurements help bound altitude errors at lower 
altitudes and are more accurate than the previously mentioned drag altitude measurement, it is unlikely 
that barometric altitude processing would be eliminated. Such a measurement would still be desirable in 
the event of one or more Shuttle systems problems that result in an unavailability of GPS data. 
Furthermore, the pitot tubes that provide the barometric altitude measurement also provide data from 
which several parameters are derived for the orbiter's flight control system. 


Precision Orbit Determination 

The Shuttle MAGR and ISS Force 19 GPS receivers did not have requirements to support precision orbit 
determination. While the existing filters in these receivers do meet requirements, flight results show they 
are not capable of precision orbit determination [23]. This function is currently performed for the Shuttle 
by Mission Control, and for the ISS by the U.S. Air Force Strategic Command and the Ballistics 
Navigation System group at the Russian Mission Control in Korolev. These solutions are used to support 
maneuver planning and debris avoidance. A Mission Control based filter, called SPOT (Spacecraft 
Position Optimal Tracking) has been developed to perform precision orbit determination using MAGR 
and Force 19 position vectors. Consideration could be given to providing a precision orbit determination 
capability on-board the orbiters. This could be done by placing a suitable filtering algorithm in either a 
GPS receiver, or in a computer external to the receiver. It may be easier to place the orbit determination 
filter in a computer other than the GPS receiver. 


Rendezvous and Proximity Operations 

Application of relative GPS is being pursued by development efforts for the European Automated 
Transfer Vehicle (ATV) and the Japanese H-II Transfer Vehicle (HTV). Similar application could be 
considered for the Shuttle as a rendezvous radar replacement. 

The Shuttle has a requirement to rendezvous with vehicles that are not equipped with active relative 
navigation aids such as relative GPS. Any replacement of a current relative sensor with relative GPS 
would have to be extensively studied to ensure that the Shuttle could still rendezvous with 
navigationally passive targets. 

To support relative GPS for Shuttle rendezvous with the ISS, a new communications link between the ISS 
and Shuttle may have to be created, with additional hardware and software added to both vehicles. The 
ISS may also need a new GPS receiver, modified to meet a relative GPS requirement. The current ISS 
receivers, and the Shuttle's current GPS receiver, were not intended to meet a relative GPS requirement. 


Relative GPS could conceivably replace the rendezvous radar and star trackers in their relative sensor 
roles. Such a replacement would permit similar navigation sensor redundancy (three GPS receivers 
versus one radar) and eliminate the need for radar failure relative navigation procedures. The Ku Band 
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antenna and associated electronics would still be required to support transmission of data and video via 
the TDRSS network satellites. In the event of a future communications system upgrade that replaces the 
Ku Band hardware communications function, replacement of the Ku Band rendezvous function by 
relative GPS would be desirable. The star trackers used for relative optical measurements are also used 
for IMU alignment, and would have to be retained in the event of a switch to relative GPS. 

Accuracy, multi-path, reliability, antenna obscuration and sensor measurement redundancy concerns in 
close proximity to the ISS would prevent relative GPS from replacing the laser sensors currently in use to 
support the close approach and docking phases. 

A GPS receiver that is to be used for relative navigation would require extensive modification of 
navigation and filtering algorithms. If the receiver could not be modified, GPS measurements could be 
passed to an on-board computer that has navigation and filtering algorithms specifically designed to 
support relative navigation during rendezvous and proximity operations. Relative GPS is also more 
complex than other relative sensors. Given the complexity of the Shuttle and ISS GPS integrations, a 
relative GPS integration effort should not be considered to be straightforward. 


Attitude Determination 

Research into GPS attitude determination has been extensive, and such an application has been 
operational on the ISS since April 2002 [2]. However, for the Shuttle, GPS attitude determination is not 
desirable. 

Multiple antennas are required for GPS attitude determination, and the ISS experience has shown that 
attitude solution quality is dependent on satellite visibility to the antenna array, which is a function of 
vehicle attitude. Mounting arrays on the Shuttle to ensure adequate visibility would be problematic. The 
Shuttle IMUs provide high accuracy attitude data during all phases of flight, at any attitude. The units 
are aligned using star trackers. The high accuracy is needed to support safety critical ascent and entry, 
where excessive attitude errors are not permissible. GPS attitude determination may not be of sufficient 
accuracy to replace the star trackers in the role of supplying attitude updates to the flight computers, for 
the purpose of IMU alignment. 


GPS Metric Tracking For Range Safety 

An effort to replace legacy ground radars with on-board GPS receivers for range safety at U.S. launch 
sites has been underway for some time. Range safety tracking requires two independent sources of 
tracking data. The Shuttle GPS receiver is integrated with the on-board navigation, guidance and flight 
control system. This would preclude the use of a new Shuttle GPS receiver from being used to reduce 
required ground tracking support during launch. An additional GPS receiver, independent of the Shuttle 
avionics system, would be required to meet range safety requirements for the Shuttle orbiters. Ground 
radar replacement for range safety would also require the addition of GPS receivers to the Solid Rocket 
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Boosters. In addition to range safety, ground radar tracking is required to support Shuttle launch and 
landings, which includes nominal and emergency landings at the Kennedy Space Center Shuttle runway. 
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12. Summary 


In the early 1990s, GPS was viewed as an off-the-shelf technology that would permit a faster-better- 
cheaper approach to upgrading vehicles and lowering development costs. GPS technology has been 
successfully integrated into the International Space Station and the Space Shuttle (the X-38/CRV project 
was canceled). GPS provides more operational flexibility and better accuracy than legacy navigation 
aids. 

However, the number of technical issues encountered exceeded the expectations held at the start of the 
projects. The amount of time, number of personnel, and effort required to resolve these technical issues 
exceeded initial estimates. GPS receivers are complex computers that interface with other complex 
computers. Treating a GPS integration with a spacecraft avionics system as a straightforward “plug and 
play" project will lead to multiple technical, cost and schedule problems. 

Extensive testing of interim software versions and the integrated system should be performed, both in 
the lab and the actual operating environment. Computer interfaces, including GPS receivers, in safety- 
critical systems should be "bullet proofed" to protect against known and postulated forms of spurious 
input. Redundancy, RAIM, satellite and ground based augmentation and monitoring systems will not 
protect against system level problems, receiver software problems, or user errors. While it is a good idea 
to equip GPS receivers with an autonomous reset feature ("ctrl-alt-delete"), the existence of such a feature 
should not be used as an excuse to take shortcuts in software and system development and testing. 
Widespread acceptance, confidence in, and use of GPS technology should not lull the integration and 
user community into thinking that problems cannot occur, particularly at the receiver level. Research 
and testing is needed to characterize receiver failures, and their probability of occurrence. 

Integration and use of software intensive, off-the-shelf units into safety related applications for which 
they were not originally designed requires vendor support and design insight above that required for 
other off-the-shelf integrations. Open communication among all participants and close relationships 
with navigation unit vendors are required to ensure success. 

The process issues encountered by GPS vendors, integrators, users, and certification authorities are not 
specific to the navigation industry. The same issues occur throughout the computer industry, and are the 
subject of research and discussion at computer industry conferences. Interaction between the computer 
software and the navigation industries may help overcome GPS software process problems. 

Not all technical difficulties with new technology should be interpreted as being process problems (lack 
of communication, inadequate requirements, insufficient testing). Application of new and revolutionary 
technology to new operating environments is a process of discovery. The Columbia Accident 
Investigation Board characterized the Shuttle as being a developmental vehicle with an operational 
mission. The NASA JSC experience with GPS in space indicates that it too is developmental in nature, 
with an operational mission. 
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